CancelAfter基于Timer实现延迟取消，不保证毫秒级精度，适用于“最多等待N秒”场景；超时失效主因是CTS提前Dispose或未正确透传Token。
CancelAfter 用法和常见超时失效问题
CancellationTokenSource.CancelAfter 是最常用的定时取消手段，但它不是“倒计时开始就一定触发取消”，而是注册一个延迟回调——如果 CancellationTokenSource 在此之前已被 Dispose 或 Cancel，那这个回调就永远不会执行。
典型错误是：在 try 块里调用 CancelAfter(3000)，但任务很快完成、cts.Dispose() 被提前执行，结果超时逻辑被静默丢弃，你以为加了超时，其实没生效。
- 必须确保
CancellationTokenSource实例在整个异步流程生命周期内保持存活（不能提前Dispose） - 不要在
using块中创建并调用CancelAfter，否则Dispose会立即释放资源 - 推荐写法：在方法作用域声明
cts，try中调用CancelAfter，finally中统一Dispose
示例关键行：cts = new CancellationTokenSource(); cts.CancelAfter(3500); await SumPageSizesAsync(cts.Token);
多个并发任务怎么统一取消
用 Task.WhenAny + 共享 CancellationToken 是最轻量的“竞速取消”方案：启动所有任务，任一完成即取消其余。它不依赖 WhenAll 的全等待语义，避免阻塞。
注意点：
- 每个
Task必须显式接收同一个cancellationToken参数，并在内部 I/O 调用（如HttpClient.GetAsync）中透传 -
WhenAny返回的是第一个完成的Task，不是结果值；需await它再取Result或检查IsFaulted - 未完成的任务不会自动释放资源，必须靠
cancellationToken触发内部取消逻辑（比如 HttpClient 会中断连接）
错误示范：var tasks = urls.Select(u => ProcessURLAsync(u, client)).ToArray(); —— 这里没传 token，取消信号根本进不去 HTTP 层。
UI 场景下按钮点击取消为什么没反应
WPF/WinForms 中点击“取消”按钮无效果，90% 是因为 CancellationTokenSource 实例作用域不对或被重复创建。
核心原则：取消源（CancellationTokenSource）必须是类成员级变量，且每次启动新任务前要新建实例（不能复用已 Cancel 过的）。
- 别在事件处理方法里写
var cts = new CancellationTokenSource()—— 按钮点击时它已经丢了引用 - 正确做法：类字段声明
private CancellationTokenSource? _cts;，点击“开始”时_cts = new CancellationTokenSource()，点击“取消”时_cts?.Cancel() - 务必检查异步方法是否真的用了这个 token：比如
client.GetAsync(url, _cts.Token)，漏传就会绕过取消链
常见报错：OperationCanceledException 没被捕获，导致 UI 线程崩溃；建议在顶层 try/catch 中专门捕获它并做 UI 清理。
HttpClient 请求取消失败的底层原因
HttpClient 的取消能力高度依赖底层 socket 行为。即使你传了有效的 CancellationToken，以下情况仍可能让请求“无视取消”：
- DNS 解析阶段卡住（.NET 6+ 已优化，旧版本需手动设置
DnsClient或改用HttpClientHandler.MaxConnectionsPerServer限流） - 服务器迟迟不发响应头，socket 处于 SYN_SENT 或 ESTABLISHED 等待状态，OS 层未触发可中断事件
- 自定义
HttpMessageHandler未正确传递cancellationToken到底层Stream.ReadAsync调用
验证方式：在 catch (OperationCanceledException ex) 中打印 ex.CancellationToken.IsCancellationRequested，若为 false，说明取消信号根本没抵达网络栈——大概率是 handler 链路断了或超时时间设得太短（比如 CancelAfter(100)），还没走到 DNS 就触发了。
