cancelpendingrequests仅对未进入发送阶段的请求有效，已发出的请求须用cancellationtoken；httpclient应长期存活，避免过早dispose；超时与取消需统一用cancellationtokensource控制。
HttpClient.CancelPendingRequests 为什么不起作用
因为 CancelPendingRequests 只对「尚未进入发送阶段」的请求有效——比如还在连接池排队、DNS 解析中、或 TLS 握手未完成的请求。一旦请求已发出（SendAsync 返回了 Task<httpresponsemessage></httpresponsemessage>），它就不再响应这个方法。
常见误用场景：在 UI 线程调用 client.CancelPendingRequests() 后仍看到网络请求继续发出去、后台线程仍在处理响应，甚至引发 ObjectDisposedException。
- 真正可控的取消入口只有
cancellationToken参数，必须传给SendAsync或GetAsync等所有异步方法 -
CancelPendingRequests适合用在客户端即将销毁前做「尽力清理」，不能当作业务逻辑中的可靠取消手段 - 若需批量取消多个正在运行的请求，应统一管理这些请求对应的
CancellationTokenSource实例，而非依赖 client 级别方法
超时设置：Timeout 属性 vs CancellationTokenSource
HttpClient.Timeout 是每个请求的「总耗时上限」，从调用 SendAsync 开始计时，到收到完整响应体结束。但它无法中断底层连接建立或 SSL 握手过程（.NET Core 2.1+ 已修复部分握手阻塞，但 DNS 超时仍不可控）。
而 CancellationTokenSource 提供更细粒度控制：可随时触发取消、可关联多个操作、支持延迟取消（CancelAfter）、还能捕获取消原因（是否被用户主动取消？是否超时？）。
- 推荐组合用法：
var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10));，再传入SendAsync(request, cts.Token) - 不要同时设
client.Timeout = TimeSpan.FromSeconds(5)和cts.CancelAfter(TimeSpan.FromSeconds(10))—— 两者独立触发，可能造成重复异常或掩盖真实问题 - DNS 超时不受
Timeout管控；如需控制，得换用HttpClientHandler.DnsRefreshTimeout（.NET 6+）或自行封装 DNS 查询逻辑
Dispose HttpClient 后还抛出 OperationCanceledException？
这是典型资源释放顺序错误导致的：在 HttpClient 已 Dispose 的情况下，仍有未完成的 Task 持有其引用，当该 Task 最终完成或被取消时，会尝试访问已释放的内部状态，从而抛出看似“取消失败”的异常（实际是对象生命周期冲突）。
根本原因不是取消逻辑写错了，而是 HttpClient 被过早释放。
-
HttpClient应作为单例或静态成员长期存活，**绝不**在每次请求后new HttpClient().Dispose() - 如果必须按需创建，务必确保所有基于它的异步调用已完成（
await到底），再调用Dispose - 使用
using var client = new HttpClient();是危险模式——编译器生成的Dispose调用发生在using块末尾，但异步方法可能早已返回未完成的Task
如何安全地取消正在进行的上传/下载请求
大文件上传或流式下载容易卡在读取/写入阶段，此时仅靠 CancellationToken 可能无法及时中断底层 socket 或磁盘 I/O。.NET 默认不会主动中断正在执行的 Stream.ReadAsync 或 Stream.WriteAsync。
关键点在于：HttpClient 本身不接管流读写，它只负责 HTTP 协议层；真正的阻塞发生在你自己的 Stream 操作上。
- 上传时，用
HttpContent.CreateContentReadStream(cancellationToken)并在自定义Stream中定期检查cancellationToken.IsCancellationRequested - 下载时，避免直接
response.Content.ReadAsByteArrayAsync()，改用response.Content.ReadAsStreamAsync()+ 手动分块读取，并在每块读取前检查 token - 若使用
Progress<t></t>报告进度，注意其回调也在Task上下文中执行，不要在里面做同步阻塞操作，否则会拖慢取消响应
最常被忽略的一点：CancellationToken 的取消信号只是“建议”，不是强制指令。所有参与协作的代码（包括你自己写的流包装器、第三方中间件、甚至某些反病毒软件注入的 hook）都必须尊重它——否则超时和取消就会失效。
