大文件中断后能否续传：先看范围请求与文件完整性

大文件下载到一半中断，重新点击后进度条突然从中间开始，很容易让人以为浏览器已经自动续传。另一种情况是进度重新归零，却很快追上原位置。两种画面都不能单独证明文件接续成功，因为续传不是浏览器单方面决定，还要看服务器接受了哪一段请求，以及资源版本有没有改变。

续传从字节范围开始

RFC 9110定义的Range请求，让客户端只要求资源的一段字节。服务器可以接受这个范围，也可以忽略Range并返回完整表示。后者通常意味着重新取得完整内容，而不是沿用磁盘上的旧片段。因此，进度条位置只是界面结果，HTTP状态和响应范围才是传输证据。

MDN说明，服务器可用Accept-Ranges表明支持字节范围。一次范围请求被接受时，常见结果是206 Partial Content，Content-Range会写出本次返回的起点、终点和完整资源长度。成功的单一范围请求通常返回206与Content-Range；若响应是200，则可能从头取得完整表示。

旧片段必须对应同一版本

下载中断后，远端文件可能已经更新。RFC 9110的If-Range用于处理这个边界：验证器仍匹配时请求缺少范围，不匹配时发送完整表示。验证器可以来自合适的ETag或Last-Modified；弱ETag不能承担If-Range所需的强比较。

这个机制防止浏览器把旧版前半段和新版后半段直接拼接。它也说明文件名相同并不足以判断版本。重新请求若拿到新的ETag、不同修改时间或不同完整长度，原有片段就不应被当成当然可续接的基础。

206、200与416分别收窄什么

206是部分响应，200可能是重新取得完整表示。416 Range Not Satisfiable则表示请求范围无法满足，例如起点已经超出当前资源长度。它不等于线路中断，也不能单凭状态码判断文件为什么改变。

MDN还区分范围请求与分块传输编码。前者由客户端指定想取得的资源区间，适合大型文件的暂停和恢复；后者是传输一份响应时的编码方式。看到数据分段到达，不代表磁盘上已有文件具备续传条件。

保留一条能够比较的记录

中断发生后不要删除原下载项。记录中断时间、文件大小、状态码、Content-Range与验证器，再重新发起一次请求。第二次若返回206，而且范围起点紧接现有片段，才有证据支持“正在续接”；若返回200，则把它视为一份重新取得的完整响应。

本地临时文件与相同大小都不能单独证明文件完整。浏览器可能尚未完成改名、校验或写入，也可能保留一个不可打开的片段。最终文件仍应以系统能否正常识别、应用能否完整读取，以及发布方提供的校验信息为准；修改扩展名不会修复缺失内容。

结论只停在传输边界

一次中断可能来自本地休眠、存储空间、网络切换、服务器连接或资源更新。范围响应能说明服务器交付了哪一段，却不能替这些原因作诊断。把206、200、416、验证器和本地文件属性放在同一条时间线上，才能分清续传、重下与片段失效，也不会把进度条变化误写成线路结论。

资料来源

• RFC Editor：《RFC 9110: HTTP Semantics》，发布或更新于 2022-06-01
• MDN Web Docs：《HTTP range requests》，发布或更新于 2025-07-04