Thread.Abort 被废弃且危险，因其强行注入 ThreadAbortException，不尊重执行状态，可能导致资源泄漏、死锁或数据损坏；.NET Core+已完全移除，应改用 CancellationToken 等协作式取消机制。
Thread.Abort 为什么被废弃且危险
因为 Thread.Abort 不是“停止线程”，而是“向线程注入一个不可控的异常”——ThreadAbortException。它不尊重线程当前执行状态，强行中断可能发生在任意位置：正在写文件、持有锁、调用非托管代码（如 P/Invoke）、或处于 finally 块中间。虽然 finally 仍会执行，但一旦抛出后无法真正捕获并“吞掉”，除非调用 Thread.ResetAbort()（极不推荐）。
- 在 .NET Core / .NET 5+ 中，
Thread.Abort已**完全移除**，编译直接报错 - 即使在旧版 .NET Framework 中，它也标记为
[Obsolete]，微软明确不建议使用 - 调用后线程状态变为
ThreadState.AbortRequested，但实际终止时间不确定；若线程卡在非托管代码中（如WaitForSingleObject），Abort可能永远不生效 - 无法保证资源释放安全（比如数据库连接、文件句柄未显式关闭）
CancellationToken 是现代 C# 的标准解法
它把“中止”变成一种协作机制：工作线程主动轮询取消信号，自己决定在哪个安全点退出。这是唯一被官方文档、Task、async/await 全面支持的方式。
- 适用于所有新项目，兼容
Task.Run、Parallel.ForEachAsync、HttpClient.SendAsync等现代 API -
CancellationToken是轻量值类型，无锁、无内存泄漏风险 - 可绑定超时（
cancellationTokenSource.CancelAfter(3000)）、可组合多个 token（CancellationTokenSource.CreateLinkedTokenSource）
var cts = new CancellationTokenSource();
var task = Task.Run(() =>
{
while (!cts.Token.IsCancellationRequested)
{
Console.WriteLine("Working...");
Thread.Sleep(500);
}
Console.WriteLine("Gracefully stopped.");
}, cts.Token);
<p>// 3秒后请求取消
cts.CancelAfter(3000);
task.Wait(); // 等待完成布尔标志 + volatile 适合简单同步场景
当不用 Task、只用裸 Thread 且逻辑极简（如后台轮询）时，volatile bool 是最轻量、最可控的替代方案。但它不提供超时、通知、组合能力，仅限“你知我停”。
- 必须用
volatile修饰变量，否则其他线程可能永远看不到值变化（CPU 缓存/编译器重排序） - 不能替代
CancellationToken在异步 I/O 或长时间阻塞调用中的作用（比如Socket.Receive会一直卡住） - 主线程必须调用
thread.Join()确保真正结束，不能只设标志就完事
class SimpleWorker
{
private volatile bool _stopRequested = false;
public void Start() => new Thread(Work).Start();
public void Stop() { _stopRequested = true; }
<pre class='brush:php;toolbar:false;'>private void Work()
{
while (!_stopRequested)
{
Console.WriteLine("Tick...");
Thread.Sleep(1000);
}
Console.WriteLine("Stopped.");
}}
ManualResetEventSlim 用于精确控制暂停/恢复/终止
当你需要不止“启停”，还要支持“暂停中”、“继续执行”、“彻底退出”三态控制时，ManualResetEventSlim 比布尔标志更语义清晰，且支持等待超时和跨线程信号传递。
- 比
AutoResetEvent更轻量，适合高频轮询 - 调用
.Set()表示“允许运行”，.Reset()表示“暂停”，而“终止”由额外标志或异常配合完成 - 注意：它本身不表示“已终止”，只是控制执行流；真正的清理逻辑仍需放在循环外或
try/finally中
真正复杂的服务型线程（如消息消费者、定时任务调度器），往往要组合 CancellationToken + ManualResetEventSlim + 显式资源释放，而不是依赖任何“强制杀线程”的幻想。
