大附件断点续传下载靠哪个请求头，服务端不支持时会返回什么

大附件的断点续传下载靠哪个请求头：靠的是请求头里的 Range。客户端在下一次请求里写明「我要从哪个字节开始」，服务器如果支持范围请求，就用 206 Partial Content 只返回这一段；服务端不支持范围请求时会返回什么是第二个问题——它会直接忽略这个请求头，把整份资源返回并给出 200。理解断点续传失败的原因，关键就在后两种情况的区分上。

三个状态码分别说明什么

按协议文档的口径：有效的范围返回 206，服务器按请求的字节区间给出部分内容；范围无效（例如起始位置超过文件长度）返回 416 Range Not Satisfiable；不支持范围请求的服务器则忽略该头、返回整份资源与 200。

这里最容易误判的是第三种。客户端看到 200 会以为是「自己没带上范围请求头」，实际上服务器已经明确表达了一次「我不支持」。文档也提到，早年的下载工具会看响应头里的 Accept-Ranges: none 来主动关掉暂停与续传功能，但由于「忽略范围请求头」本身就有同样的含义，这种写法现在很少见了。

判断顺序因此很清晰：先发一次 HEAD 或 OPTIONS 请求，看响应里是否有 Accept-Ranges: bytes；有，再谈续传；没有或值为 none，就说明这条链路只能整份重下。

字节偏移从零开始，右端可以省略

范围写法用的是闭区间，起始与结束位置都按字节算，而且计数从零开始。常见写法有三种：只给起始位置表示「从这里到文件末尾」，给完整区间表示一段精确范围，给负数表示「只要末尾那几个字节」。

一个请求头里可以同时写多段，服务器可能以多段文档的形式返回。但对续传来说，更值得利用的是另一条性质：当请求头里只指定单段字节区间时，这个头属于跨域场景下的安全列表请求头，跨域请求不需要先走预检。这正是媒体分段取用与下载器续传常用的组合——单段既好处理，又不会因为跨域多一次往返。

大文件在站点上的两类场景

站里出现「需要续传的大附件」通常是两类。一类是备份文件下载：数据连同静态文件的备份包体积取决于站点内容量，几百兆以上时一次完整下载失败的概率明显上升，能否从断点继续直接决定运维体验。另一类是批量导入的原始包：通过压缩包或表格做批量导入时，上传侧更在意单次请求的体积上限，下载侧才是范围请求的主场。

两类都要注意同一件事：范围请求是否可用，取决于最终吐出文件的那一层。程序自己生成下载响应时按规范写 206 与相关头即可；若前面还挂着网关或缓存，需要确认这一层不会把范围请求整个吞掉或返回不带区间信息的 200。

改完之后建议用三种情形各验一次：从头开始的单段请求、超过文件长度的无效区间（应返回 416）、以及对同一个地址的完整请求（应返回 200 且带 Accept-Ranges: bytes）。三种返回都对，断点续传才算真正可用。

常见问题

问：返回 200 是不是配置错了？ 答：不一定。不支持范围请求时忽略该头并返回整份资源是规范允许的行为，此时应改用完整下载，或确认是哪一层不支持。

问：为什么续传时反复拿到整个文件？ 答：多半是中间层把范围请求转成了完整请求。逐层核对是否透传该请求头与 206 响应，比只改下载逻辑更有效。

问：一次要多个区间更省吗？ 答：多段会引入多文档响应与解析成本。除特殊场景外，续传按单段区间处理更简单，也更容易跨域直连。