HttpClient 默认不处理 multipart/byteranges 响应，因其仅传递原始响应体而不解析复合格式，需手动按 boundary 分割、校验并拼接各 part；浏览器则内置解析器，而 C# 缺乏对应 HttpContent 支持。
为什么 HttpClient 默认不处理 multipart/byteranges 响应
因为标准 HTTP 客户端（包括 HttpClient）只负责收响应体，不解析 multipart/byteranges 这种复合格式——它把整个响应当做一个 blob 交给你，后续拆分、拼接、校验都得自己来。浏览器能自动处理，是因为它们内置了完整的 multipart 解析器；而 C# 没有现成的 HttpContent 子类支持这个 MIME 类型。
常见错误现象：HttpResponseMessage.Content.ReadAsByteArrayAsync() 返回一串乱码或开头是 --boundary 的原始字节，直接写文件就损坏；或者用 StringContent 尝试反序列化，抛出 JsonReaderException ——其实压根不是 JSON。
- 必须手动按 boundary 提取每个 part，不能依赖
HttpContent.ReadAsStringAsync() -
Content-Type响应头里带的boundary=...是关键，不能硬编码 - 每个 part 的
Content-Range头决定该段数据应写入文件的哪个偏移位置
怎么从 HttpResponseMessage 中安全提取 multipart/byteranges 片段
核心是：用 Stream 逐字节扫描 boundary，避免一次性加载大响应到内存，尤其对 GB 级文件。
实操建议：
- 先读响应流到
MemoryStream或临时文件（如果确定总大小可控），否则用BufferedStream+ 手动 boundary 查找 - 用
Encoding.UTF8.GetString()解析 boundary 字符串时，注意响应可能用ISO-8859-1编码（尤其服务端是 Nginx/Apache） - 每个 part 的 header 和 body 之间是空行，但有些服务端多写一个
\r\n，要用\r\n\r\n或\n\n双重匹配 - 别信
Content-Length：multipart 响应的这个头通常是整个复合体长度，不是单个 part 的
示例关键逻辑：
var boundary = "--" + response.Content.Headers.ContentType.Parameters.First(p => p.Name == "boundary").Value; var parts = SplitByBoundary(responseStream, boundary); // 自定义分割函数，返回 (headers, bodyStream) 元组
C# 文件服务器如何正确返回 multipart/byteranges（ActionResult 场景）
ASP.NET Core 不提供开箱即用的 multipart/byteranges 支持，PhysicalFileResult 和 FileStreamResult 都只走单段响应流程。必须手写 ActionResult 并控制整个响应流。
容易踩的坑：
- 忘记设置
Content-Type: multipart/byteranges; boundary=xxx，客户端直接当普通二进制处理 - 每个 part 的
Content-Type写成text/plain而不是原始文件 MIME 类型（如application/pdf） -
Content-Range格式写错，比如漏掉总长度：bytes 0-999/10000，不能只写bytes 0-999 - 用
Response.Body.WriteAsync()直接写 byte[]，没做await或没调用Response.Body.FlushAsync()，导致部分 part 丢失
关键参数差异：单段用 206 Partial Content，multipart 响应也必须是 206，但状态行后要立即输出 boundary 行和 headers。
边界处理和性能陷阱：为什么 boundary 不能随便生成
boundary 不是 UUID，它是 HTTP 协议约定的分隔符，必须满足 RFC 7233 要求：不能出现在原始文件内容中。用 Guid.NewGuid().ToString() 有极小概率撞上文件里的相同字符串，导致解析错位。
实操建议：
- 用
Convert.ToBase64String(RandomNumberGenerator.GetBytes(16))生成高熵 boundary - 生成后检查是否在文件前 8KB 内出现（用
File.OpenRead()扫描），冲突则重试 —— 这步常被跳过，但对 PDF/ZIP 类二进制文件很关键 - 不要把 boundary 放进 URL 或 query string，某些 CDN 会截断或转义特殊字符
- 并发下载时，多个请求共用同一个 boundary 字符串没问题，但每个响应必须独立计算并写入自己的 headers
最麻烦的点往往不在代码逻辑，而在服务端返回的 Content-Range 和客户端期望的 range 请求范围不一致——比如客户端请求 bytes=0-1023,2048-3071，服务端却返回了 bytes=0-1023/5000 和 bytes=2048-3071/5000，但中间缺了 1024–2047，客户端就卡住不动。这事没法靠库自动兜底，只能靠严格校验 range 参数再构造响应。
