HttpCompletionOption.ResponseHeadersRead 是什么，为什么高并发下载时必须用它
它告诉
HttpClient在收到响应头后就立即返回
Task<httpresponsemessage></httpresponsemessage>，而不是等整个响应体（比如几百 MB 的文件）全部下载完才返回。高并发场景下，如果不用这个选项，每个请求都会在内存中缓冲完整响应体，极易触发
OutOfMemoryException或严重拖慢吞吐量。 默认行为是
HttpCompletionOption.ResponseContentRead，适合小响应（如 JSON API），不适合大文件流式处理 启用
ResponseHeadersRead后，你必须手动调用
response.Content.ReadAsStreamAsync()获取流，并自行控制读取节奏 它不改变连接复用、超时或重试逻辑，只影响“何时算请求完成”
如何配合 Stream.CopyToAsync 实现无内存堆积的并发下载
拿到响应流后，不能直接
await response.Content.ReadAsByteArrayAsync()——这又会把整个文件加载进内存。必须用流式复制，且显式控制并发数，避免打爆目标服务器或本地 socket 限制。
var client = new HttpClient();
// 注意：务必设置 Timeout 和 MaxConnectionsPerServer
client.Timeout = TimeSpan.FromMinutes(10);
var handler = client.Handler as HttpClientHandler;
if (handler != null) handler.MaxConnectionsPerServer = 100;
var downloadTasks = urls.Select(async url =>
{
var response = await client.GetAsync(url, HttpCompletionOption.ResponseHeadersRead);
response.EnsureSuccessStatusCode();
using var stream = await response.Content.ReadAsStreamAsync();
using var file = File.Create($"./downloads/{Path.GetFileName(url)}");
await stream.CopyToAsync(file); // 内部按 81920 字节块分批读写，不占大内存
});
CopyToAsync默认 buffer size 是 81920，已足够高效；不必手动
Read/Write循环 务必对
HttpClient设置
MaxConnectionsPerServer，否则 .NET 默认仅 2 个连接，高并发会排队阻塞 不要为每个下载新建
HttpClient，复用实例并配置好生命周期
常见错误：忘了 Dispose HttpResponseMessage 或流未关闭导致句柄泄漏
使用
ResponseHeadersRead后，
HttpResponseMessage不再自动管理底层连接——如果你没读完流或提前丢弃了
response，连接可能卡在 CLOSE_WAIT 状态，最终耗尽可用 socket。 必须确保
response.Content.ReadAsStreamAsync()被调用，哪怕只读前几个字节；否则连接不会释放 即使下载失败（如网络中断），也要在
catch块中调用
response?.Dispose()不要在
using var response = ...里只检查状态码就
return，那会跳过流读取和 dispose 推荐结构：
try { stream = await response.Content.ReadAsStreamAsync(); ... } finally { response?.Dispose(); }
性能关键点：Buffer size、同步 I/O 与 CancellationToken 传递
CopyToAsync支持自定义 buffer size 和
CancellationToken，这两项在高并发长下载中直接影响稳定性与响应性。
await stream.CopyToAsync(file, bufferSize: 65536, cancellationToken);bufferSize 设为 64KB–128KB 通常比默认值更适应千兆网卡和 SSD 写入节奏 务必把外部
CancellationToken传给
CopyToAsync，否则取消请求时可能还在写磁盘，无法及时退出 避免在
FileStream构造时用
FileOptions.Asynchronous——.NET 6+ 的
CopyToAsync已默认异步，重复设置反而可能降低性能 注意：Windows 上
FileOptions.WriteThrough会强制刷盘，大幅降低写速，仅调试时用
真正容易被忽略的是连接池耗尽和流未读完之间的隐式耦合——只要有一个请求没走到
ReadAsStreamAsync()，它就在后台悄悄占用一个连接，而你从监控里几乎看不到异常日志。
