C#怎么实现文件分片下载_C#如何计算HTTP请求范围【源码】-C#.Net教程-PHP中文网

用httpclient分片下载需复用实例、设range头为bytes=start-end、检查206状态码；响应流须filestream偏移写入，禁用appendallbytes；多线程应每分片独用filestream，避免竞态。

c#怎么实现文件分片下载_c#如何计算http请求范围【源码】

怎么用 `HttpClient` 发起带 `Range` 头的分片请求

分片下载本质就是让服务器只返回文件某一段字节，关键在发请求时加 Range 请求头。C# 里最稳妥的方式是用 HttpClient 手动设置，而不是依赖 DownloadFileAsync 这类黑盒方法——它不支持断点续传或自定义范围。

实操要点：

HttpClient 实例必须复用（别每次新建），否则可能触发连接池耗尽或 TIME_WAIT 爆增
务必设置 client.DefaultRequestHeaders.Range，不是拼字符串到 Headers.Add；后者容易被忽略或覆盖
范围格式严格为 bytes=start-end（如 bytes=0-1023），end 是包含的，且不能超过文件总大小（否则服务器返回 416）
响应状态码必须检查：成功是 206 Partial Content，不是 200；收到 200 说明服务器没支持分片，得 fallback

示例片段：

client.DefaultRequestHeaders.Range = new System.Net.Http.Headers.RangeHeaderValue(0, 1023);

如何安全读取 `HttpContent` 的原始字节并写入文件偏移位置

拿到响应后，不能直接 content.ReadAsStringAsync() 或 ReadAsByteArrayAsync()——它们会把整个流缓存进内存，大文件直接 OOM。必须用流式读取 + FileStream 的 Position 或 Write 偏移写入。

常见错误现象：

用 File.AppendAllBytes：它每次打开文件追加，无法写到指定 offset，且频繁打开关闭损耗大
用 FileStream.Write 但没提前设置 Position：字节全堆在文件开头，覆盖已有内容
没处理 HttpContent.ReadAsStreamAsync() 返回的流是否支持 Seek：HTTP 响应流通常不支持，所以只能顺序读、顺序写

正确做法是：打开 FileStream 时用 FileMode.Open + FileAccess.Write，再调 fs.Position = startOffset，然后 await stream.CopyToAsync(fs)。

怎么判断服务器是否真正支持分片（`Accept-Ranges` 不可靠）

Accept-Ranges: bytes 只是声明“可能支持”，不代表本次请求真能分片。很多 CDN 或 Nginx 配置漏掉 add_header Accept-Ranges bytes，或者对某些路径禁用了范围请求。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

更可靠的验证方式是实际发一个试探请求：

先 HEAD 请求目标 URL，看响应头有没有 Accept-Ranges，有则继续
再发一个真实 Range: bytes=0-0 的 GET 请求，检查状态码是否为 206 且响应体长度为 1
如果返回 200 或 416，说明不支持，得降级为整包下载

注意：某些服务器（如 IIS 默认配置）对小范围（如 0-0）会静默转成 200，所以最好试 0-1023 并比对 Content-Range 头是否匹配。

多线程并发分片时，`FileStream` 写入为什么崩了

多个 Task 同时往同一个 FileStream 写，即使各自写不同 offset，也会因底层缓冲、Position 竞态、或 Windows 文件锁机制出错——典型报错是 System.IO.IOException: The process cannot access the file 或写入错位。

根本原因不是“没加锁”，而是 FileStream 本身不是线程安全的写入对象。解决方案只有两个：

每个分片用独立的 FileStream（FileMode.Open + FileAccess.Write + fs.Position = offset），写完立刻 Dispose；开销可控，且无竞争
用单个 FileStream 但配全局 object 锁 + Position 设置 + Write，性能差，还容易死锁，不推荐