HttpClient断点续传核心是手动设置Range请求头并复用实例；需用FileMode.Open+Seek写入指定偏移，验证206状态码与Content-Range响应头；并发分片须独立Seek且避免超限。
如何用 HttpClient 发起带 Range 请求的下载
断点续传的核心是让服务器只返回文件的一部分，这依赖 HTTP 的 Range 请求头。C# 中最稳妥的方式是用 HttpClient 手动设置该头，而不是依赖 WebClient（它不支持自定义请求头且已过时）。
关键点：
-
HttpClient实例应复用，不要每次新建——避免端口耗尽和连接池问题 - 必须显式设置
Accept-Ranges: bytes不起作用，真正生效的是客户端发出去的Range: bytes=1024- - 服务端是否支持取决于其响应头是否含
Accept-Ranges: bytes或Content-Range字段；若返回 200 而非 206，说明不支持断点 - 示例代码片段：
var client = new HttpClient();<br>client.DefaultRequestHeaders.Range = new System.Net.Http.Headers.RangeHeaderValue(1024, null);<br>var response = await client.GetAsync("https://example.com/file.zip", HttpCompletionOption.ResponseHeadersRead);
如何安全地追加写入已存在的下载文件
断点续传不是“重新下载再合并”，而是从断点位置开始写入磁盘。直接用 FileMode.Append 会出错——它只适用于文本追加，二进制流必须精确控制偏移量。
正确做法是打开文件为 FileMode.Open + FileAccess.Write，再调用 Stream.Seek() 定位到末尾：
- 先用
new FileInfo(path).Length获取已下载字节数，作为下次请求的Range起始值 - 用
FileStream打开时务必指定FileShare.Read，否则其他进程（如杀毒软件）可能锁住文件导致写入失败 - 写入前检查磁盘剩余空间，避免写到一半因空间不足而中断
- 别用
StreamWriter或BinaryWriter，直接用Stream.WriteAsync()写原始字节
如何判断服务器是否真正支持断点续传
光看响应状态码不够：有些服务器对 Range 请求返回 200（全量）却不报错，导致你误以为续传成功，实际重复下载了前面部分。
必须验证响应头：
- 成功支持的标志是响应状态码为
206 Partial Content，且包含Content-Range头，例如Content-Range: bytes 1024-9999/10000 - 如果返回
200 OK，即使有Accept-Ranges: bytes，也不能认为支持——它只是声明“理论上支持”，实际可能被中间代理或 CDN 屏蔽 - 建议首次请求时先发一个试探性
HEAD请求，检查Accept-Ranges和Content-Length，再决定是否启用断点逻辑
并发下载多个分片时要注意什么
把大文件切分成多个 Range 并发下载能提速，但容易踩坑：
- 不是所有服务器允许高并发 Range 请求，Nginx 默认限制单 IP 每秒请求数，IIS 更严格——可能触发 429 或直接断连
- 每个分片需独立管理
FileStream，且写入前必须用Seek()定位到对应偏移，不能依赖顺序 - 最终合并不是“拼接文件”，而是按分片起始位置写入同一文件的指定区域；写错 offset 会导致文件损坏
- 推荐先用单线程验证断点逻辑跑通，再逐步加并发；超过 4 个分片后收益通常递减，还增加出错概率
断点续传真正的难点不在“怎么发 Range”，而在于对网络异常、服务端策略、本地 I/O 权限和文件系统行为的容错处理——比如临时磁盘满、杀毒软件拦截、HTTP/2 流重置、甚至 NTFS 稀疏文件标记干扰 Seek。这些细节不写日志根本没法定位。
