恢复中断的传输：永远不必从零开始
了解可恢复文件传输的工作原理。使用支持断点续传的服务，大文件上传再也不会丢失进度。
可恢复传输将文件切分为若干分块，并追踪哪些分块已被服务器成功接收；连接中断时，客户端从下一个未发送的分块继续，而不是从字节零重新开始。这一领域的 Web 标准是 tus.io（开放的可恢复上传协议），SwissTransfer、HexaTransfer、Vimeo、Cloudinary 以及许多现代传输服务均已实现该协议。下载端则由 HTTP Range 请求（RFC 7233）支持，浏览器和 curl、aria2 等工具可据此恢复中断的下载。若没有断点续传能力，一个 9.8 GB 的上传在传至 9.5 GB 时中断，代价是全部丢失——有了断点续传，最多只损失约 50 MB。
不支持断点续传的上传有何代价
传统文件上传将整个文件作为一个 HTTP POST 请求发送。任何中断——Wi-Fi 断开、VPN 超时、笔记本休眠、ISP 网络抖动——都会关闭 TCP 连接，服务器丢弃收到的所有部分数据，客户端从零字节重新开始。
对于 50 Mbps 连接上 5 GB 的上传，这意味着 13 分钟的工作付之东流。对于 50 GB 的上传，则超过两小时。非断点续传在移动网络上的失败率极高——4G 连接上进行 30 分钟的上传，第一次成功的概率非常低。
可恢复协议的工作原理
现代可恢复上传的基本流程如下：
- 创建： 客户端向服务器发送 POST 请求，携带文件总大小和元数据。服务器返回该次上传专属的 URL 并预留存储空间。
- 分块： 客户端将文件切分为若干分块（通常每块 5—64 MB）。
- 上传： 客户端将每个分块作为 PATCH 请求发送，并在 Content-Range 或 Upload-Offset 头中指明该分块的位置。
- 确认： 服务器将分块写入存储并确认新的偏移量。
- 恢复： 连接中断后，客户端向上传 URL 发送 HEAD 请求。服务器以当前偏移量（已收到的字节数）响应，客户端从该位置继续。
- 完成： 最后一个分块确认后，上传完成。
该模型由 tus.io 规范定义（1.0.0 版本已广泛部署）。其他变体包括 S3 Multipart Upload（用于直接 S3 上传）和 Google Cloud Storage Resumable Uploads。
tus.io：开放标准
tus（"transloadit upload server"）是由 Transloadit 维护的免费开放协议，规范发布于 tus.io，已被以下各方实现：
- 客户端库： tus-js-client（浏览器 + Node.js）、TUSKit（iOS）、tus-android-client、tus-java-client
- 服务端实现： tusd（Go 语言参考服务端）、tus-node-server 及多种框架集成
- 商业服务： SwissTransfer、HexaTransfer、Vimeo、Cloudinary、Transloadit、Uppy 的配套服务端
该协议刻意保持精简：四个 HTTP 动词（POST、HEAD、PATCH、OPTIONS），少量头字段（Upload-Offset、Upload-Length、Tus-Resumable）。这使实现简单、互通性强。
分块大小的选择
分块大小在恢复粒度与 HTTP 开销之间取得平衡。
| 分块大小 | 失败时最多重传量 | 请求开销 |
|---|---|---|
| 1 MB | ≤ 1 MB | 高（请求数多） |
| 5 MB | ≤ 5 MB | 中等 |
| 16 MB | ≤ 16 MB | 低 |
| 64 MB | ≤ 64 MB | 极低 |
| 256 MB | ≤ 256 MB | 几乎无开销，但失败代价大 |
稳定连接上，32—64 MB 分块能最大化吞吐量。移动网络或不稳定 Wi-Fi 上，2—5 MB 分块恢复更快。服务通常默认 5—10 MB 作为折中方案。
哪些因素会中断传输
了解故障模式有助于评估服务的断点续传实现是否健壮：
- Wi-Fi 断开： 切换网络、信号丢失、路由器重启——极为常见
- 笔记本休眠： 在 macOS/Windows 上合上盖子，系统暂停网络；唤醒后连接通常需要重新建立
- 标签页挂起： 现代浏览器会挂起后台标签页以节省内存，处于挂起状态的标签页中的上传可能停滞
- ISP/骨干网问题： 短暂路由变更、需要重新进行 TLS 握手
- VPN 重连： VPN 客户端会定期重新协商，TCP 连接因此中断
- 服务端重启： 传输服务部署新版本时，进行中的请求会失败
- 企业防火墙干预： 正在检测流量的企业防火墙有时会切断长时间运行的连接
健壮的断点续传实现对以上所有场景采用相同机制：重新连接，发送 HEAD 请求查询偏移量，从该处继续。
下载端的断点续传
HTTP Range 请求（RFC 7233）驱动可恢复下载。在响应头中声明 Accept-Ranges: bytes 的服务器支持范围请求。客户端可发送 Range: bytes=1000000- 来只获取从偏移量 1,000,000 字节起的数据。
浏览器在你点击"恢复"时会自动使用这一机制。Chrome、Firefox 和 Safari 均支持从合规服务器恢复下载。大多数 CDN（Cloudflare、Fastly、CloudFront）也支持范围请求。
命令行工具控制更精细：
curl -C - -O url——从中断处恢复下载wget -c url——效果相同aria2c -c -s 16 url——通过 16 路并行范围请求加速下载
支持断点续传的服务
现代传输服务大多支持上传断点续传：
| 服务 | 上传续传 | 下载续传 |
|---|---|---|
| SwissTransfer | 支持（基于 tus） | 支持（HTTP 范围请求） |
| HexaTransfer | 支持（分块 + tus 兼容） | 支持 |
| WeTransfer | 支持（分块上传） | 支持 |
| Dropbox Transfer | 支持 | 支持 |
| Google Drive | 支持（可恢复上传 API） | 支持 |
| OneDrive | 支持 | 支持 |
| Box | 支持 | 支持 |
免费版有时会禁用断点续传以引导用户升级付费，但在 2026 年这种情况已较为少见。不支持断点续传的老旧服务正在逐渐淡出推荐列表，因为用户不愿忍受频繁失败。
哪些场景不自动恢复
朴素的 HTTP POST 上传不支持恢复。FTP 传输历史上表现各异——部分客户端和服务器支持 REST（重启）命令，其他则不支持。邮件附件无法恢复——Gmail 发送失败在 90% 时，只能从头开始。
基于 BitTorrent 的传输天然支持断点续传，因为 torrent 协议会追踪哪些分块已验证完成。这也是即使 Web 传输在其他方面已经追赶上来，BitTorrent 在大型发布场景下仍保持价值的原因之一。
端对端加密与断点续传
将断点续传与客户端加密结合，需要谨慎处理分块方式。文件被分割为若干分块，每个分块用 AES-256-GCM 加密（使用唯一的 IV 初始向量），再逐块上传。恢复时，客户端需要知道哪些分块已完成，并从下一个分块继续。
由于每个分块独立加密并经过认证（GCM 的 AEAD 模式），部分上传内容无法被篡改。恶意服务器若在偏移量 5 GB 处插入垃圾数据，接收方解密时会因 GCM 标签不匹配而检测到并拒绝。
HexaTransfer 等实现为每个分块的 IV 从主密钥和分块索引确定性派生，因此恢复时无需单独存储 IV。解密端通过相同的派生方式重建 IV。
客户端最佳实践
最大限度提高断点续传成功率：
- 上传期间保持标签页活跃。 浏览器挂起标签页会终止进行中的上传。传输服务界面通常有"请勿关闭此标签页"的提醒。
- 尽量接有线网络。 Wi-Fi 断开是导致失败的主因。
- 长时间上传期间禁用省电休眠。 macOS：
caffeinate -i；Windows：使用 Powertoys Awake 工具或修改电源计划。 - 上传中途不要切换 Wi-Fi 网络。 TCP 连接会因 IP 变更而中断。
- 合上笔记本盖前等待上传完成。 现代 macOS 有时能在短暂休眠后保持上传，但并不可靠。
在服务端验证结果
部分服务显示的进度条并不能真实反映服务端状态。经历过一两次中断的上传完成后，刷新页面并验证链接是否有效——在隐身窗口中打开链接并下载一小部分。如果断点续传正常，完整文件应能正确下载。
追求万无一失时，在客户端计算文件的 SHA-256 哈希，上传完成后将下载文件的哈希与之对比。加密文件完整性校验每吉字节大约需要 10 秒 CPU，能给出绝对确定的结论。
总结
断点续传在 2026 年已是基本功能——任何不支持此功能的服务，对于几百兆字节以上的文件都是直接排除项。寻找符合 tus.io 的服务，或具备等效分块上传行为的服务。确保所选服务能优雅地处理中断；在提交大型传输任务前，先用一个小文件故意制造网络断开来测试一下。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。