主动取消 Task 需协作式机制：传入 CancellationToken 并在任务中调用 ThrowIfCancellationRequested() 或检查 IsCancellationRequested，尤其 CPU 密集型任务须手动轮询；超时取消应结合 CancellationTokenSource 与 WaitAsync。
用 CancellationToken 主动取消正在运行的 Task
不能靠“杀掉”或“中断线程”来取消 Task，.NET 的设计原则是协作式取消：任务内部必须主动响应取消信号。核心机制是 CancellationToken，它本身不执行取消，只是传递一个“该停了”的通知。
常见错误是只传了 CancellationToken 却没在任务体里检查它，结果超时后任务仍在后台跑着——看起来“没取消”。
- 必须把
CancellationToken传进Task.Run或异步方法，并在关键位置调用token.ThrowIfCancellationRequested()或轮询token.IsCancellationRequested - 如果任务调用的是支持取消的 API（如
HttpClient.GetAsync(..., token)、Stream.ReadAsync(..., token)），直接传入即可，它们内部会响应并抛出OperationCanceledException - 不要在
catch (OperationCanceledException)里“吞掉异常”却不 rethrow —— 这会让外层await task误以为任务成功完成
Task.WaitAsync(TimeSpan) 是最简明的超时等待方式
这是 .NET 6+ 引入的原生支持，用于“等一个 Task 完成，但最多等 X 秒”。它不取消 Task 本身，只控制等待行为；若超时，抛出 TimeoutException，而原始 Task 仍在运行（除非你额外传入 CancellationToken）。
真正要实现“超时即取消”，得组合使用：
var cts = new CancellationTokenSource(TimeSpan.FromSeconds(3));
try
{
await myTask.WaitAsync(cts.Token); // 等待任务完成，同时监听取消信号
}
catch (OperationCanceledException)
{
// 超时触发取消，这里捕获的是取消异常，不是 TimeoutException
Console.WriteLine("Task was cancelled due to timeout.");
}
catch (TimeoutException)
{
// WaitAsync 自身超时（极少发生，仅当 cts.Token 未被触发时）
}
注意：WaitAsync 的参数是 CancellationToken，不是 TimeSpan；超时逻辑由 CancellationTokenSource 控制，更可控。
手动轮询 + ThrowIfCancellationRequested 防止死循环
当任务体是 CPU 密集型（比如复杂计算、无 await 的循环），没有自然暂停点，就必须显式插入取消检查，否则 CancellationToken 永远不会生效。
错误写法：
Task.Run(() =>
{
for (int i = 0; i <p>正确写法：</p><pre class="brush:php;toolbar:false;">Task.Run((token) =>
{
for (int i = 0; i
- 避免在循环内频繁调用（如每毫秒一次），合理间隔即可，比如每 10–100 次迭代检查一次
- 如果循环里有阻塞调用（如
Thread.Sleep），优先换成带 token 的异步替代（如Task.Delay(..., token)）
取消后资源清理容易被忽略
调用 cts.Cancel() 只是发信号，不代表所有资源已释放。比如任务中打开了文件流、数据库连接、HTTP 连接，这些必须在 finally 或 using 中显式处置。
尤其要注意：某些异步操作（如未完成的 HttpClient 请求）即使被取消，底层 TCP 连接可能仍处于 TIME_WAIT 状态，大量超时取消可能引发端口耗尽。
推荐模式：
var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
try
{
await DoWorkAsync(cts.Token);
}
catch (OperationCanceledException) when (cts.IsCancellationRequested)
{
// 明确是用户/超时触发的取消，可记录日志
Console.WriteLine("Work cancelled.");
}
finally
{
// 确保清理，哪怕没走到 catch
cts.Dispose();
}
真正难的不是设超时，而是判断哪些地方该检查 token、哪些资源必须清理、哪些异常该透出——这些取决于你的任务具体做什么。
