应限制 httpclient 并发连接数、使用 throttledstream 精准节流、按租户动态配额并确保 cancellationtoken 全链路传递，避免带宽抢占与状态泄漏。
上传时 CPU 占用高但网卡没跑满，HttpClient 默认行为在“抢带宽”
默认情况下，HttpClient 不限制并发连接数或单请求吞吐，尤其在多用户同时上传大文件时，它会尽可能把可用带宽占满——不是因为你想压满，而是因为它根本不知道“该留点给别人”。这会导致小文件上传延迟飙升、后台任务卡住、甚至触发服务器限流。
实操建议：
- 用
HttpClientHandler.MaxConnectionsPerServer控制全局连接上限（例如设为4），避免 TCP 连接泛滥 - 对每个上传任务单独封装
HttpContent，并在写入流时主动节流：用Stream.CopyToAsync(dest, bufferSize, cancellationToken)配合自定义bufferSize（如8192）降低瞬时吞吐 - 不要复用同一个
HttpClient实例做“混传”（比如同时上传用户头像和日志归档），不同优先级任务应走不同实例 + 不同 handler 配置
ThrottledStream 手动限速比等系统调度更可靠
靠 Thread.Sleep 或 Task.Delay 节流不精准，且容易被 GC 或线程池抖动干扰；而基于 Stream 包装的限速器能直接卡在数据泵送环节，对上传速率控制更稳。
常见错误现象：上传速度忽高忽低、限速目标（如 512KB/s）长期偏差 >20%。
实操建议：
- 继承
Stream写一个轻量ThrottledStream，重写ReadAsync，每次读完后计算已用时间，不足则await Task.Delay补齐 - 限速单位统一用字节/秒（
bytesPerSecond），别用 KB/s 或 MB/s 做配置项——避免整数除法截断（512 * 1024必须写死，不能靠math.Round） - 把限速逻辑放在
FileStream→ThrottledStream→HttpContent链路中，**不要**在HttpContent构造完再包一层——那样只限了内存拷贝，没限真实网络发送
按用户身份动态切限速策略，用 ConcurrentDictionary 管理配额
硬编码一个全局限速值（比如所有用户都 1MB/s）既不公平也不安全。真实场景需要区分 VIP 用户、普通用户、后台任务——它们的带宽权重、突发容忍度、超时策略都不同。
使用场景：SaaS 后台提供 API 文件上传服务，需支持租户隔离与 QoS。
实操建议：
- 用
ConcurrentDictionary<string int></string>存用户 ID → 允许的bytesPerSecond，键名建议用"tenant:{id}"或"task:backup"明确作用域 - 上传前查字典取限速值，查不到则 fallback 到默认值（如
256 * 1024），**不要抛异常**——限速缺失不该导致上传失败 - 避免在上传过程中反复查字典（比如每 1KB 查一次），应在初始化
ThrottledStream时一次性读取并缓存 - 注意字典本身无过期机制，若需动态调整配额，配合
MemoryCache或外部配置监听（如IOptionsMonitor）
上传中断后带宽没释放？检查 cancellationToken 是否穿透到底层流
用户取消上传、网络闪断、服务器返回 413，这些情况若没正确传播 CancellationToken，节流逻辑可能还在空转，占用线程和缓冲区，后续上传变慢。
错误现象：TaskCanceledException 捕获到了，但上传线程没退出，CPU 持续 15%~20%。
实操建议：
- 所有异步 I/O 调用（
ReadAsync、WriteAsync、CopyToAsync）必须传入同一CancellationToken -
ThrottledStream.ReadAsync中，若cancellationToken.IsCancellationRequested为 true，立即返回Task.FromCanceled，**不要**等 Delay 结束 - 在
HttpClient.PostAsync外层加using var cts = new CancellationTokenSource(timeoutMs);，把超时和用户取消统一管理
带宽管理真正的复杂点不在“怎么限”，而在“限完之后状态是否干净”——连接是否关闭、缓冲区是否清空、计时器是否取消、字典里残留的临时配额会不会累积成内存泄漏。这些细节不处理，压测时看着正常，上线后扛不住突增流量。