manualresetevent 是轻量同步原语，仅支持 waitone() 阻塞、set() 开闸、reset() 关闸；其状态持久，set() 后所有 waitone() 立即返回，需严格配对 set/reset 并避免初始化竞态。
ManualResetEvent 不是“高级教程”的主角，它是个轻量、明确、有固定行为的同步原语——用错不是因为不够高级，而是没对齐它的设计契约。
它只做三件事：WaitOne() 阻塞、Set() 开闸、Reset() 关闸。所有复杂问题，都来自忽略「手动重置」这个前提。
WaitOne() 为什么有时不阻塞？
因为 ManualResetEvent 的状态是持久的：一旦 Set() 被调用，它就一直保持 true，后续所有 WaitOne() 都立刻返回，不再等待。
- 常见错误：在初始化时传
true（如new ManualResetEvent(true)），结果线程一启动就跳过等待，逻辑提前执行 - 典型场景：主线程启动工作线程后，不立即
Set()，而是等某个条件满足（如配置加载完成）再发信号 - 注意：没有超时的
WaitOne()是永久阻塞的，生产环境务必用带TimeSpan的重载，比如mre.WaitOne(TimeSpan.FromSeconds(10))
Set() 和 Reset() 的调用时机必须严格配对
Set() 是广播式释放，Reset() 是唯一能把它拉回等待态的操作——漏掉 Reset()，等于闸门焊死，后续所有 WaitOne() 全部失效。
- 容易踩的坑：在多线程环境中，多个线程都可能调用
Set()，但只有第一个Reset()才真正关闸；如果Reset()被跳过或异常吞掉，整个同步逻辑就不可逆地失效 - 建议：把
Set()和Reset()放在同一个逻辑上下文里，比如用try/finally确保重置，或封装成状态机方法 - 不要依赖 GC 或析构函数清理：它不实现
IDisposable的自动资源释放语义（虽然底层是WaitHandle，但 .NET 6+ 后推荐显式Dispose()）
ManualResetEvent vs AutoResetEvent：选错就卡死
二者 API 几乎一样，但语义截然不同：AutoResetEvent 每次 Set() 只唤醒一个等待线程，然后自动变回 false；ManualResetEvent 唤醒全部且永不自动关闭。
- 误用场景：用
ManualResetEvent实现“每来一个任务放行一个线程”，结果所有空闲线程全被唤醒，争抢同一份资源，引发竞态 - 正确选择依据：
– 需要“一次性全局通知”（如服务启动完成、配置热更新生效）→ 用ManualResetEvent
– 需要“逐个分发信号”（如生产者-消费者模型中每次投递一个任务）→ 用AutoResetEvent或SemaphoreSlim - 性能差异极小，别为“看起来更高效”换类型；语义错位才是最大成本
跨线程共享实例时，必须确保线程安全初始化
ManualResetEvent 本身是线程安全的，但它的引用赋值不是。如果多个线程在未完成初始化前就读取静态字段，可能拿到 null 或部分构造对象。
- 最稳妥写法：用
static readonly+ 静态构造函数，或 C# 6+ 的表达式体属性（如private static readonly ManualResetEvent Mre = new(false);） - 禁止在实例方法里懒初始化（如
if (mre == null) mre = new ManualResetEvent(false);），除非加锁或用Lazy<t></t> - 特别注意：在 ASP.NET Core 中，若在中间件或控制器里 new 出
ManualResetEvent并跨请求复用，会因生命周期错配导致信号混乱
ManualResetEvent 的复杂点从来不在 API，而在状态流转的可见性——你永远得清楚此刻它是开还是关，谁最后动了它，以及下一次 WaitOne() 到底该等还是不该等。
