应使用 CancellationToken 协作式取消而非 Thread.Abort()：线程内定期检查 token 或调用 ThrowIfCancellationRequested()，异步方法传入 token，资源释放用 using/finally 严格对齐执行生命周期，优先用 Task+async/await 替代裸线程。
用 CancellationToken 主动通知线程退出，而不是强行 Thread.Abort()
强行中止线程不仅已被标记为过时（.NET Core+ 完全移除），还会导致资源泄漏、锁未释放、对象处于不一致状态。正确做法是让工作线程“自己停下来”：通过 CancellationToken 传递取消信号，线程内部定期检查 token.IsCancellationRequested 或调用 token.ThrowIfCancellationRequested()。
常见错误是只在线程启动前检查一次 token，或在长时间阻塞操作（如 Task.Delay()、Socket.ReceiveAsync()）中忽略可取消重载。
- 所有支持取消的异步方法（如
Task.Delay(1000, token)、HttpClient.GetAsync(uri, token)）务必传入CancellationToken - 自定义循环中，每轮迭代开始或关键等待点前检查
token.ThrowIfCancellationRequested() - 不要在线程函数里捕获
OperationCanceledException后吞掉它——除非你明确要抑制取消传播
用 using 或 IDisposable 确保非托管资源及时释放
多线程场景下，资源释放时机比单线程更敏感：一个线程正在写文件，另一个线程就关闭了 FileStream，会抛出 ObjectDisposedException。所以资源生命周期必须和线程执行严格对齐。
推荐模式是把资源创建、使用、释放全部封装在同一个作用域内，优先用 using 块；若需跨多个异步步骤，确保 Dispose() 调用发生在 await 链末端，且受 try/finally 或 using 保护。
- 避免在线程外提前
Dispose()一个正被线程读写的MemoryStream或Timer -
Timer必须显式调用timer.Dispose()，否则它会持续触发回调，即使线程已退出 - 如果线程持有数据库连接、文件句柄等，应在
finally块中释放，或用using包裹整个工作逻辑
用 Task + async/await 替代裸 Thread，简化生命周期管理
手动管理 Thread.Start() / Join() / Abort() 极易出错。现代 C# 应优先使用 Task.Run() 启动后台工作，并配合 async/await 实现协作式取消与自动上下文清理。
示例中常见陷阱是忘了 await 任务，导致主线程继续执行、提前释放资源，而后台任务仍在运行：
var cts = new CancellationTokenSource();
var task = Task.Run(() =>
{
while (!cts.Token.IsCancellationRequested)
{
// 工作...
Thread.Sleep(100);
}
}, cts.Token);
// ❌ 错误：没 await，也没处理 task 结束
cts.Cancel();
// ✅ 正确：await 并处理异常
try
{
await task;
}
catch (OperationCanceledException) { / 取消正常 / }
关闭线程池线程要格外小心：别试图“关闭”它们
.NET 线程池（ThreadPool）不是你能“关闭”的对象。你只能停止向它提交新任务，并确保所有已提交的委托完成其工作后自然退出。试图强制终结线程池线程会导致运行时崩溃。
真正需要控制的是你提交的任务本身是否响应取消、是否及时释放资源。重点检查：
- 用
ThreadPool.QueueUserWorkItem()时，回调函数内必须检查CancellationToken，不能假设线程会复用就省略清理 - 避免在
ThreadPool线程中长期持有静态资源（如全局SqlConnection），这会引发竞争和泄漏 - 若需独占线程（如实时音频处理），应使用
Thread+IsBackground = false+ 显式Join()，而非依赖线程池
最常被忽略的一点：取消和释放不是两个独立动作，而是一个原子过程——资源释放逻辑必须嵌套在取消响应路径中，且顺序不能颠倒。比如先关 Timer 再清空事件订阅，否则可能触发已 disposed 的 handler。
