AutoResetEvent 不是自动信号量，构造时传 true 易致抢跑，应默认用 false；WaitOne 卡住主因是信号未发、发早或对象不同；配合 CancellationToken 应用 Register 并及时释放；ManualResetEvent 不可随意替换；高频场景应避免使用。
AutoResetEvent 不是“自动信号量”，它不计数、不累积、不广播——用错就卡死或丢信号。
AutoResetEvent 构造时传 true 为什么总出问题
传 true 表示初始状态为有信号，第一个 WaitOne() 会直接返回，不阻塞。这在多数同步场景中是危险的：你本想让工作线程严格等待主线程发号施令，结果它一启动就“抢跑”了。
- 典型表现：工作线程读取未初始化的数据、访问 null 引用、抛
NullReferenceException - 生产环境几乎全部应使用
new AutoResetEvent(false) - 只有极少数预热场景（如启动即触发一次心跳）才考虑
true，且必须配注释说明
WaitOne() 卡住不返回的三个常见原因
不是 API 坏了，而是信号没发、发早了、或发错了对象。
-
Set()根本没被调用：工作线程异常退出、逻辑分支遗漏、条件判断绕过 -
Set()在WaitOne()之前调用：信号被“吃掉”，因为 AutoResetEvent 不保存历史——Set()多次调用，只生效最后一次（如果无等待线程） - 跨线程用了不同实例：比如主线程 new 一个，又在子线程里 new 另一个，
Set()和WaitOne()完全不通信 - 补救建议：加超时，例如
ev.WaitOne(5000)；返回false时检查ev.SafeWaitHandle.IsInvalid和业务上下文
如何安全配合 CancellationToken
WaitOne() 没有原生 CancellationToken 支持，硬等会阻塞线程且无法响应取消。
- 别用轮询 +
Thread.Sleep：浪费 CPU、延迟高、逻辑臃肿 - 推荐组合：
cts.Token.Register(() => ev.Set())，并在WaitOne()后立刻检查cts.Token.IsCancellationRequested - 注意
Register()返回的IDisposable必须释放，否则可能泄漏回调引用 - 更现代的替代：.NET 6+ 直接用
SemaphoreSlim，支持await semaphore.WaitAsync(cts.Token)，无阻塞、可取消、无需手动管理句柄
为什么 ManualResetEvent 不能随便替换成 AutoResetEvent
两者语义完全不同，混用等于改写业务逻辑。
- 用
ManualResetEvent做启动屏障（多个线程等“初始化完成”），换成AutoResetEvent后，只有第一个线程能过，其余永久挂起 -
AutoResetEvent的Set()是“点对点唤醒”，ManualResetEvent的Set()是“广播通知” - 误换后现象：日志只看到一个线程执行，CPU 占用低，调试器里一堆线程停在
WaitOne()—— 这不是性能问题，是逻辑死锁
最易被忽略的一点：AutoResetEvent 是基于内核对象的，每次 WaitOne() 都涉及用户态/内核态切换。高频调用（如每毫秒一次）会明显拖慢吞吐，这种场景该用 SpinWait 或无锁队列，而不是强行套用 AutoResetEvent。
