一句话定义：HTTP Range 请求（HTTP Range Request）是浏览器或下载工具在请求头里加一行 Range: bytes=起点-终点，向服务器索要文件的某一段字节，而不是整个文件。
原理：像在图书馆借书，只借第 300 到 400 页
正常下载是一句“把整个文件给我”。服务器回 200 OK，从头到尾把文件发一遍。Range 请求则是在请求头里写清区间，服务器回 206 Partial Content，并在响应头 Content-Range: bytes 0-1023/5000000 里说明这段在全文中的位置。
服务器是否支持这种操作，由响应头里的 Accept-Ranges: bytes 表明。看到这一行，客户端就知道“可以分段要”。反之，若服务器不支持，它通常会忽略 Range，直接返回 200 和完整文件，所以客户端也要能接受这种情况。如果请求的区间超出文件长度，服务器返回 416 Range Not Satisfiable。
断点续传、视频拖动进度条、多线程分片下载模型权重，都依赖服务器返回 Accept-Ranges 这一行。
- 断点续传（resume download）：下载中断后，客户端查看本地已有多少字节，再发
Range: bytes=已下载字节数-继续获取剩余部分。为了防止文件在服务器上已被替换，客户端还可以带上If-Range、ETag或Last-Modified做校验；如果校验不通过，就重头下载。 - 视频拖动进度条：播放器并不先下完整个视频。用户拖到第 20 分钟时，播放器估算对应字节位置并发 Range 请求，只取那一小段，因此看起来是“秒开”。这也解释了为什么 MP4 文件要把索引（
moov）放在文件开头：索引在末尾时，播放器得先发一次 Range 请求，把文件尾部的索引取回来，才能知道该往哪里跳。 - 分片下载模型权重：几十 GB 的权重文件，用多线程或多进程各自负责一段字节区间，同时拉取，最后按顺序拼回原文件。下载工具的花式加速，本质上就是把一条 Range 请求拆成很多条并发执行。
和相邻概念的区别
| 概念 | 谁来决定分段 | 典型用途 |
|---|---|---|
| HTTP Range 请求 | 客户端指定字节区间 | 续传、拖动进度条、多线程下载 |
| 分块传输编码（Transfer-Encoding: chunked） | 服务端边生成边发送，客户端不指定区间 | 服务端不知道总长度时的流式响应 |
| 普通整文件请求 | 不进行分段 | 小文件、不支持 Range 的场景 |
最容易混淆的是 Range 与 chunked：前者是客户端说“我要第几段”，后者是服务端说“我一块一块发给你”。
对实际工作的意义
对 AI 从业者来说，拉取大模型权重是最常见的高频操作。支持 Range 的存储服务（不少对象存储与模型仓库都提供，具体以官方页面为准）能让下载中断后不用从头重来，也能让并发下载真正提速。自建推理服务或做数据集分发时，确认自己返回 Accept-Ranges 也很划算：一个响应头，就能换来续传和更省流量的客户端体验。
对普通职场人来说，这条规则藏在“暂停后继续下载”和“视频随便拖”的背后。你从未直接写过 Range，但每天都在使用它。