客户端请求能不能断点续传？下载大文件卡一半别慌

你有没有试过下载一个2GB的网课视频，下到85%时突然断网，再点继续——结果从头开始？这时候心里肯定嘀咕：这浏览器/APP到底支不支持断点续传啊？

断点续传不是玄学，是HTTP协议早就有的功能

简单说，断点续传就是“上次下到哪，这次接着下”。它依赖服务端和客户端双方配合。客户端发请求时带上 Range 头，比如：

Range: bytes=1024000-

意思是“请把从第1024000字节开始的后续内容给我”。如果服务端返回状态码 206 Partial Content，并附上对应数据块，那这个请求就算成功续上了。

不是所有客户端都默认开这个开关

微信内置浏览器、部分国产APP的下载模块，为了省事或兼容老系统，压根不发 Range 请求，而是用最原始的 GET 全量拉取。所以你点“继续”，它其实偷偷新建了一个请求，自然从头来过。而Chrome、Firefox、Edge这些主流浏览器，在下载大文件时默认就支持，只要你没关掉开发者工具里的网络限速或禁用缓存，一般都能续。

怎么一眼看出当前请求支不支持？

打开浏览器开发者工具（F12），切到 Network 标签页，找那个正在下载的请求，点开看 Headers → Request Headers 里有没有 Range；再看 Response Headers 里有没有 Accept-Ranges: bytes 或者响应状态是不是 206。有，就说明通路是通的。

生活小技巧：手动续传也行得通

比如你用 curl 下载课程包，中途断了，可以这样续：

curl -C - -o course.zip https://example.com/course.zip

其中 -C - 就是告诉 curl：“查一下本地文件已下多少，接着往下拿”。很多命令行工具和专业下载器（如 aria2）都内置这个逻辑，比网页点点点更靠谱。

下次再遇到下载卡住重来一遍，先别急着骂网速，看看是客户端太“老实”，还是服务器压根没配好 Accept-Ranges ——有时候问题不在你家WiFi，而在对方那台没开续传权限的服务器上。