想省流量钱，断点续传先试哪种方案更稳妥

上周同事在群里发了一张手机截图：下载到 68% 的想省安装包停住不动，进度条卡在“正在重试”四个字上，流量运营商提示当月流量只剩 300MB。钱断他问的点续其实不是“怎么下载”，而是传先“断点续传怎样做最小成本尝试”——先用最小的代价验证方案能不能跑通，再决定要不要投入。试种

这句话落到具体工程里，更稳常见的想省起手有两种：一种是基于 HTTP Range 的服务端分段，另一种是流量客户端把已落盘的分片记成清单、失败后按清单续传。钱断两者都能叫断点续传，点续但适用边界差得很远，传先选错了，试种省下的更稳不是钱，是想省返工时间。

先看服务端接不接 Range 请求

第一种做法最省事：客户端在请求头里带上 Range: bytes=已下载字节数-，服务端返回 206 状态码和对应片段。判断标准很硬——拿 curl -I -H "Range: bytes=0-99" 目标地址 看一眼，回来的是 206 且 Content-Range 对得上，说明这条路通；回来是 200 且整包长度，说明服务端把 Range 忽略了，你写再多客户端逻辑也是白搭。

它适合什么场景？静态资源、对象存储、CDN 后面的文件，绝大多数原生支持。最小成本尝试就是一条命令加一次失败重跑，验证成本接近零。选错的后果也很具体：把不支持 Range 的接口硬套这套逻辑，客户端每次都从头拉，进度条反复归零，用户以为在续传，其实在重复付费。

客户端分片清单什么时候更划算

第二种做法是把文件切成固定大小的分片，每片落盘后写一条记录，失败重来时只补没写完的片。它不依赖服务端配合，代价是客户端要多维护一份清单文件，还要处理“清单写了、数据没刷盘”这种半成功状态。

适用边界是：接口不支持 Range、下载过程容易中断、或者需要多线程并发拉取。比如某些导出接口一次性吐整包、没有分段能力，这时候清单方案就是唯一选择。但选错方向的后果同样明确——文件只有几 MB、网络稳定，却上来就搞分片加并发，清单读写和合并逻辑反而成了新的故障点，调试时间远超省下的那点流量。

这里插一句，很多人搜“断点续传怎样做最小成本尝试”，真正想要的是先跑一个几十行的验证脚本，而不是直接上框架。验证脚本的写法可以很朴素：记录已写字节数，重跑时从这个偏移继续写，跑通再谈并发和校验。

用 20MB 文件做一次对照实验

具体怎么试？找一个 20MB 左右的公开文件，先测 Range 方案：下载到一半手动掐断，重跑时看服务端是否返回 206、本地文件是否从断点继续增长。再测清单方案：把同一文件切成 1MB 分片，掐断后看清单里已完成的片是否被跳过、合并后的文件大小和哈希是否一致。

两次实验各花不到半小时，但结论很值钱：Range 通就优先用 Range，代码量少、边界清楚；Range 不通再上清单，并且先把“清单写入”和“数据落盘”的先后顺序定死，避免清单说完成了、文件其实是空的。哈希校验这一步别省，它是判断续传是否真的成功的唯一硬指标。

失败时先查响应码再改代码

如果第一次尝试就失败，下一步不是加功能，是看响应。返回 200 说明服务端没接 Range，换清单方案；返回 416 说明请求的区间越界，检查本地记录的字节数是不是超过了文件实际大小；返回 206 但内容对不上，多半是缓存或代理改写了响应头，换直连地址再试一次。

边界也要说清：涉及登录态、签名 URL 的下载，断点续传还要考虑链接过期，过期后 Range 请求会被拒，这时候得先刷新地址再续，不能只盯着字节偏移。真要上线给大量用户用，校验、重试上限、磁盘空间检查都得补，这些已经超出“最小成本尝试”的范围，该找负责存储和后端的同事一起定。

回到那张卡在 68% 的截图：先花一条命令确认服务端认不认 Range，再决定要不要写清单。省成本的顺序是先验证边界，再写代码，而不是反过来。