manualresetevent适用于一个线程发信号、多个线程等待的简单同步场景，如主线程等待多个工作线程完成；不适用于需超时、取消、轮流执行或跨进程通知等复杂场景，此时应选用task、countdownevent或channel。
ManualResetEvent 什么时候该用，什么时候不该用
它只适合「一个线程发信号、多个线程等响应」这种简单同步场景。比如主线程启动一堆工作线程后，想等它们全部完成再继续——这时 ManualResetEvent 比 AutoResetEvent 更合适，因为不用反复 Set()。但如果你要协调几十个线程轮流执行、或需要超时/取消/跨进程通知，它就力不从心了，该换 Task、CountdownEvent 或 Channel。
初始化和基本用法：true 和 false 参数的区别
ManualResetEvent 构造函数只接受一个 bool 参数，决定初始状态是「已触发」还是「未触发」：
-
new ManualResetEvent(false)：默认阻塞，所有WaitOne()调用会挂起，直到有人调Set() -
new ManualResetEvent(true)：初始就放行，第一次WaitOne()立即返回，后续仍需Set()才能再次通过（除非你手动Reset()）
绝大多数情况用 false，避免逻辑错乱。比如你本意是等子线程做完才继续，结果因初始化为 true 导致主线程直接跳过等待。
WaitOne() 的坑：不带参数、带毫秒数、带 TimeSpan，全都不一样
WaitOne() 行为差异直接影响程序是否卡死或误判：
-
waitHandle.WaitOne()：无限等待，线程彻底挂起，无超时、不可被CancellationToken中断 -
waitHandle.WaitOne(1000)：最多等 1 秒，返回bool——true表示等到了，false表示超时（注意：不是异常！） -
waitHandle.WaitOne(TimeSpan.FromSeconds(2))：语义更清晰，推荐用于可读性要求高的地方
别在 UI 线程或 ASP.NET 同步上下文中用无参 WaitOne()，容易导致界面冻结或请求假死。生产环境建议始终带超时，并检查返回值。
Set() 和 Reset() 必须配对使用，否则状态会漂移
Set() 是单向开关：调一次，所有等待线程全部唤醒，且之后所有 WaitOne() 都立刻返回，直到你显式调 Reset() 把它扳回「未触发」状态。
常见错误：
- 只调
Set()不调Reset()，第二次等待就直接通过，逻辑失控 - 多个线程并发调
Set()，没问题；但并发调Reset()可能覆盖彼此，导致漏重置 - 在
finally块里漏写Reset()，尤其在异常路径中
实战建议：把 Set() 放在工作完成的确定位置（如子线程末尾），把 Reset() 放在每次等待前（或封装成方法统一处理）。别指望靠「只 Set 一次」来简化逻辑——状态管理必须显式、对称。
复杂点在于：它不记录「谁 Set 的」「Set 了几次」，也没有回调机制。一旦你发现需要这些能力，说明已经超出了它的设计边界。
