服务器端把大文件变成支持 HTTP Range 的可寻址片段，配上短时效鉴权链接和 CDN 分发；手机端用系统下载器或自研队列做分片拉取、断点续传和完整性校验，下载功能才算真正可靠。这两件事必须同时成立，少一头都会在弱网或大文件场景里出问题。
下载链路到底由哪几段组成
一次手机端下载,表面是点一下按钮，背后至少经过四段：客户端发起请求 → 服务端鉴权并签发资源地址 → 边缘节点回源或命中缓存 → 客户端落盘并校验。
业内专家指出,下载体验的分水岭不在峰值带宽，而在失败重试和续传能力，移动网络会切 Wi-Fi、会进电梯、会被系统杀进程，这些都不是异常，而是常态，设计时把“下载可能随时中断”当成前提，思路会顺很多。
一个典型的下载请求长这样：
curl -I -H "Range: bytes=0-1048575" \ "https://dl.example.com/app/v3.2.1.apk?sign=xxx&expires=1735689600"
服务端应返回 206 Partial Content，并带上：
Content-Range: bytes 0-1048575/52428800Accept-Ranges: bytesETag或Last-Modified
客户端拿到这些头,才知道文件总大小、能不能续传、续传时文件有没有变。
服务端怎么把下载接口设计好
用 HTTP Range 支撑断点续传
Range 是断点续传的地基，Nginx 默认开启 Accept-Ranges，静态文件直接支持；如果是对象存储，OSS、COS 这类服务默认也支持分片读取，需要自己写接口时，要正确解析 Range 头，越界返回 416，并在响应里写明 Content-Range: bytes /总大小。
续传前必须校验文件一致性,客户端带上 If-Range: <ETag>，服务端比对不通过就返回 200 全量，通过才返回 206 续传，少了这一步，用户可能拿到新旧版本拼接出来的坏包。
下载链接的鉴权和防盗链
直接暴露裸链接,等于把带宽账单交给别人，常见做法是签名 URL：路径 + 过期时间 + 客户端 IP 或设备指纹，用 HMAC 算签名，服务端校验，链接有效期多数情况下控制在几分钟到几小时。
Nginx 里可以用 secure_link 模块做校验，也可以用应用层签发、X-Accel-Redirect 内部重定向到真实文件，这样真实路径不出外网。
限速与并发保护
单个用户把带宽跑满,会影响同机房其他请求，Nginx 可以用：
location /download/ {
limit_rate 1024k;
limit_conn addr 4;
}
limit_rate 控制单连接速率，limit_conn 控制单 IP 并发连接数，移动端场景下，单连接限速配合多分片并发，往往比放开单连接更快也更公平。
大文件分片与秒传
安装包、视频、离线地图这类文件动辄几百 MB，做法是上传时先算文件哈希，服务端已有就直接秒传；下载时按固定大小切片（常见 1MB 到 4MB 一片），客户端并发拉取后按序合并，切片大小不是越小越好，片太多会放大请求开销，太少又不利于并发调度。
手机客户端下载功能怎么实现
Android 端的三条路
- 系统 DownloadManager：适合普通文件下载，系统负责通知栏进度、断网重试、Wi-Fi 优先，缺点是定制能力弱，进度回调粒度粗。
- WorkManager + OkHttp：可控性最好，能做分片、限速、加密、自定义通知，配合前台服务保活。
- 自研前台服务：适合超大文件或需要后台持续传输的场景，Android 14 起前台服务要声明
dataSync类型。
存储上别再用外部存储裸路径,Android 10 之后走 MediaStore 或应用私有目录，下载到公共下载目录需要用 MediaStore.Downloads 插入。
通知权限要注意：Android 13 起需要动态申请 POST_NOTIFICATIONS，否则下载进度通知不显示，用户会以为卡住了。
iOS 端的后台下载
iOS 的关键是 URLSession 的后台配置：
let config = URLSessionConfiguration.background(
withIdentifier: "com.example.download"
)
config.isDiscretionary = false
let session = URLSession(configuration: config, delegate: self, delegateQueue: nil)
后台会话由系统接管传输,App 被挂起甚至被杀，下载仍会继续，系统会在下载完成后把 App 拉起来，走 handleEventsForBackgroundURLSession 回调，这里有个必须遵守的规则：在 didFinishDownloadingTo 里，文件会被系统删除，要立刻拷贝到自己的目录，晚一步就没了。
下载状态的统一管理
不管哪个平台,客户端都需要一个下载任务表，记录任务 ID、URL、已下载字节数、分片状态、校验值，App 启动时恢复未完成任务，把“下载中”但实际已中断的任务标回“暂停”，Android 用 Room，iOS 用 Core Data 或 SQLite，思路一致。
完整性校验放在合并之后：服务端提供整包 MD5 或 SHA-256，也可以给每个分片的哈希，客户端逐片校验再合并，这样能挡住代理劫持和传输截断。
手机客户端下载速度慢怎么优化
先分清是服务端慢还是链路慢,用 curl -o /dev/null -w "%{speed_download}" 在目标地区实测，再对比 CDN 节点命中率。
CDN 与边缘节点
下载类业务对回源率敏感,把安装包、静态资源放到 CDN，设置合理的缓存过期时间，开启分片回源，能显著降低首字节时间，国内做下载业务，节点覆盖和运营商穿透是关键，选型时重点看三网覆盖和单节点带宽储备。
并发数与分片大小
单文件 3 到 5 个并发连接是比较稳的区间，再多，弱网下重传开销会吞掉收益，多文件排队下载时，总并发数要设上限，避免抢占用户其他网络请求。
几个容易踩的坑
- 服务端返回
200而不是206，客户端续传逻辑直接失效。 - 开了 gzip 压缩下载二进制文件，Range 语义被破坏。
- 重定向到 CDN 后丢了鉴权参数，边缘节点返回 403。
- iOS 后台会话没设
sessionSendsLaunchEvents，App 被拉起后拿不到回调。
手机下载功能开发成本多少
自建和买服务差别很大,下面按常见方案做个量级对比，具体报价随文件体积、并发量、地域差异浮动。
| 方案 | 适用场景 | 成本构成 | 量级参考 |
|---|---|---|---|
| 对象存储 + CDN 自建 | 自有 App、中等下载量 | 存储费、流量费、开发人力 | 流量单价在每 GB 几毛钱量级 |
| 第三方下载 SDK | 快速上线、少维护 | SDK 授权 + 流量 | 按调用量或包年计费 |
| 完全自研传输层 | 超大文件、强管控 | 服务器带宽 + 长期人力 | 带宽成本占大头 |
| P2P 辅助分发 | 用户量大、热点资源 | 调度服务 + 开发 | 能省一部分回源流量 |
行业共识认为,下载量到一定规模后，流量成本会超过开发成本，这时优化分片命中率和缓存策略的收益，比继续加服务器更明显。
Q&A：服务器与手机客户端下载功能常见问题
问：APP 内下载和网页直接下载有什么区别？
网页下载靠浏览器自己的下载管理器,服务端只要能处理 Range 就能续传，APP 内下载多了一层：要自己管任务队列、通知、存储路径和断点恢复，还要处理后台被系统限制的情况，服务端接口可以共用，客户端工作量差好几倍。
问：断点续传一定要服务端支持吗？
是,客户端只能决定“从第几字节开始要”，能不能给出来取决于服务端是否返回 206 和正确的 Content-Range，纯静态文件服务器开箱即用，动态生成的下载接口必须自己实现 Range 解析。
问：手机端下载完成后文件校验失败，一般是什么原因？
多数是续传时文件被替换而没校验 ETag，或者服务端对二进制响应启用了压缩传输，导致字节偏移错位，iOS 后台下载回调里没有及时转移临时文件，也会拿到不完整的文件，排查顺序是：先看响应头是否带 Accept-Ranges 和 ETag，再看是否启用了 gzip，最后检查客户端合并分片的顺序。