Dispose中禁止调用Thread.Abort()，应改用CancellationToken协同取消Task；需用Interlocked确保Dispose线程安全；IAsyncDisposable不解决并发问题，仅用于异步释放场景。
Dispose 方法里直接调用 Thread.Abort() 会出问题
很多老代码习惯在 IDisposable.Dispose() 中暴力终止线程，比如调用 Thread.Abort()。这在 .NET Core / .NET 5+ 已被彻底移除，即使在 .NET Framework 中也极不安全——它可能在任意指令中间断线程，导致静态字段损坏、锁未释放、内存泄漏或 ThreadAbortException 意外抛出到非预期上下文。
- 永远不要在
Dispose()中调用Thread.Abort() - 避免手动管理
Thread实例；优先用Task+CancellationToken - 若必须用
Thread（如需设置IsBackground = false或特定优先级），应配合手动退出信号（如ManualResetEvent或volatile bool）
正确做法：用 CancellationTokenSource 协同取消长期运行的 Task
现代 C# 中，绝大多数后台工作应封装为可取消的 Task，并在 Dispose() 中触发取消并等待完成（带超时）。关键点不是“杀掉线程”，而是“通知工作逻辑自行退出”。
public class Worker : IDisposable
{
private readonly CancellationTokenSource _cts = new();
private Task? _workerTask;
public void Start()
{
_workerTask = Task.Run(() => DoWork(_cts.Token), _cts.Token);
}
private void DoWork(CancellationToken ct)
{
while (!ct.IsCancellationRequested)
{
// 模拟工作：I/O、计算、延时等
Thread.Sleep(100);
// 关键：所有阻塞调用都应支持 cancellation
// ✅ ct.WaitHandle.WaitOne(1000)
// ✅ Task.Delay(1000, ct)
// ❌ Thread.Sleep(1000) —— 无法响应取消
}
}
public void Dispose()
{
_cts.Cancel(); // 发出取消信号
// 等待任务自然退出（建议加超时）
_workerTask?.Wait(2000); // 最多等 2 秒
_cts.Dispose();
_workerTask?.Dispose();
}}
Dispose 被并发调用时的线程安全风险
IDisposable.Dispose() 可能被多个线程同时调用（尤其在依赖注入容器或异步资源清理场景中），而标准实现通常没加锁。不处理会导致重复释放、ObjectDisposedException、或资源二次关闭（如 FileStream.Close() 被调两次）。
- 用
Interlocked.CompareExchange(ref _disposed, 1, 0)做一次性标记最轻量 - 避免在
Dispose()中加lock—— 若内部释放逻辑本身阻塞（如等待网络响应），可能引发死锁 - 对非托管资源（如句柄、内存指针），仍需在
~Worker()终结器中兜底释放，但终结器不能访问托管对象（包括CancellationTokenSource）
异步 Dispose（IAsyncDisposable）不是万能解药
.NET 5+ 提供 IAsyncDisposable，但它只解决“释放过程本身需要 await”的场景（如异步刷新缓冲区、等待远程服务确认），**并不解决多线程并发 Dispose 的问题，也不替代取消逻辑**。
- 若
DisposeAsync()内部要 await 长时间操作，仍需先触发取消（_cts.Cancel()），再 await 任务完成 - 不能仅因用了
IAsyncDisposable就忽略同步Dispose()的线程安全 —— 两者可能被不同线程分别调用 - 常见误区：把
await Task.Delay()当作“等待线程结束”，实际只是挂起当前 async 上下文，和目标线程无关
真正难的不是写完 Dispose()，是确保所有阻塞点都响应取消信号，并且整个释放流程在并发、重入、提前中断等边界条件下依然稳定。多数崩溃不是因为没写 Dispose，而是写了但没想清楚「谁在什么时候、以什么方式停止了什么」。
