用 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);
<p>// ❌ 错误：没 await，也没处理 task 结束
cts.Cancel();</p><p>// ✅ 正确：await 并处理异常
try
{
await task;
}
catch (OperationCanceledException) { /<em> 取消正常 </em>/ }关闭线程池线程要格外小心：别试图“关闭”它们
.NET 线程池（
ThreadPool）不是你能“关闭”的对象。你只能停止向它提交新任务，并确保所有已提交的委托完成其工作后自然退出。试图强制终结线程池线程会导致运行时崩溃。
真正需要控制的是你提交的任务本身是否响应取消、是否及时释放资源。重点检查：
用ThreadPool.QueueUserWorkItem()时，回调函数内必须检查
CancellationToken，不能假设线程会复用就省略清理 避免在
ThreadPool线程中长期持有静态资源（如全局
SqlConnection），这会引发竞争和泄漏 若需独占线程（如实时音频处理），应使用
Thread+
IsBackground = false+ 显式
Join()，而非依赖线程池
最常被忽略的一点：取消和释放不是两个独立动作，而是一个原子过程——资源释放逻辑必须嵌套在取消响应路径中，且顺序不能颠倒。比如先关
Timer再清空事件订阅，否则可能触发已 disposed 的 handler。
