Thread.Suspend()和Thread.Resume()因在任意指令点中断线程，可能持有锁、执行非托管操作或处于JIT编译态，极易引发死锁、内存泄漏或崩溃，且无协作机制；.NET 2.0起弃用，Core/5+已移除，应改用ManualResetEvent等协作式暂停方案。
不能用 Thread.Suspend() 和 Thread.Resume()，它们在 .NET Framework 2.0 就被标记为过时，.NET Core / .NET 5+ 中已彻底移除 —— 不是“不推荐”，是根本调用不了。
为什么 Suspend/Resume 被废弃？
核心问题不是“不好用”，而是“无法安全实现”：
-
Thread.Suspend()可能在任意指令点中断线程，包括正在持有锁、执行非托管资源释放、或处于 JIT 编译中间态时 —— 极易引发死锁、内存泄漏或 AppDomain 崩溃 - 挂起时机不可控：.NET 会尝试延迟到“安全点”，但无法保证；而你写的业务逻辑（比如数据库事务、文件写入）根本不关心什么安全点
- 没有协作机制：被挂起的线程完全被动，无法清理资源、保存状态或响应取消请求
ManualResetEvent 是最常用替代方案
它不挂起线程，而是让工作线程主动“等信号” —— 这是协作式暂停，可控、可中断、可超时。
关键结构：
private readonly ManualResetEvent _pauseEvent = new ManualResetEvent(true); // 初始为 true，表示“允许运行”
private volatile bool _shouldStop;
public void HeavyWork()
{
while (!_shouldStop)
{
// 模拟一段工作
DoSomeCalculation();
// 检查是否应暂停：WaitOne(0) 非阻塞检查，返回 false 表示当前被暂停
if (!_pauseEvent.WaitOne(0))
{
// 线程在此处“停住”，直到 UI 调用 _pauseEvent.Set()
_pauseEvent.WaitOne(); // 阻塞等待恢复信号
}
}
}
UI 线程控制逻辑：
- 点击“暂停” →
_pauseEvent.Reset()（变为非信号态，后续WaitOne()阻塞） - 点击“继续” →
_pauseEvent.Set()（变为信号态，唤醒所有等待该事件的线程） - 点击“停止” →
_shouldStop = true，再_pauseEvent.Set()（确保唤醒后能退出循环）
AutoResetEvent 为什么不适合做暂停控制？
它只放行一个等待线程，且自动重置 —— 这会导致两个典型问题：
- 如果工作线程在循环中多次调用
WaitOne()（比如每步都检查），Set()只能唤醒一次，下一轮又卡住，行为不可预测 - 多个工作线程共用同一个
AutoResetEvent实例时，Set()只唤醒其中一个，其余继续挂起，违背“全部暂停/恢复”的设计意图 -
ManualResetEvent的“手动重置”特性才是关键：一次Set()让所有线程持续运行，直到你显式Reset()
容易被忽略的细节
真正上线时，这几个点常被跳过，但一出问题就难定位：
-
_pauseEvent必须是实例字段，不能是局部变量 —— 否则每次调用HeavyWork()都新建一个，UI 根本控制不到 - 工作循环里不能只有
WaitOne()，必须配合_shouldStop检查，否则无法响应停止请求 - 如果工作方法里有 long-running 非循环操作（比如单次
File.Copy或HttpClient.SendAsync），需在调用前检查_pauseEvent.WaitOne(0)，否则暂停会卡在 I/O 内部 - WPF/WinForms 中更新 UI 必须用
Dispatcher.Invoke或BeginInvoke，不能在线程里直接操作控件
