WaitOne() 行为差异是核心区别
不是“能不能用”，而是“用完要不要管”：
AutoResetEvent.WaitOne()每次唤醒**一个**等待线程后，**自动调用 Reset()**，事件立刻回到无信号（
false）状态；
ManualResetEvent.WaitOne()唤醒**所有**当前等待线程后，**保持有信号（
true）状态不变**，直到你手动调用
Reset()。 没调
Reset()的
ManualResetEvent，后续所有
WaitOne()都直接通过——相当于“闸门一直开着” 没调
Set()的
AutoResetEvent，哪怕只差 1 毫秒，
WaitOne()就会永久阻塞（除非超时） 两个类的
WaitOne(1000)都支持超时，超时返回
false，不抛异常
构造函数参数 initialState
决定“第一次是否拦人”
new AutoResetEvent(false)和
new ManualResetEvent(false)是最常用写法： 首次
WaitOne()必然阻塞，必须等别人
Set()才能继续。 而
new AutoResetEvent(true)相当于“开门即放行一次”，第一个
WaitOne()立刻返回，之后立即变回
false；
new ManualResetEvent(true)则是“门一开始就开着”，所有
WaitOne()都直接过，直到你
Reset()。 别靠猜——用
false初始化最安全，逻辑清晰 用
true初始化容易引发竞态：比如主线程刚 new 完，子线程就
WaitOne()了，结果啥都没等就往下跑了
典型使用场景不能混用
选错类型会导致线程“该醒不醒”或“不该醒全醒了”：
生产者-消费者单次通知（如：一个任务完成，唤醒一个处理线程）→ 用AutoResetEvent（例：日志写入线程完成 flush 后，只唤醒一个归档线程） 初始化完成广播（如：配置加载完毕，让所有工作线程同时开始）→ 用
ManualResetEvent（例：主线程加载完配置后
Set()，5 个后台服务线程在
WaitOne()处一起启动） 资源池限流（如：最多允许 3 个线程并发访问）→ 不该用这两个，该用
SemaphoreSlim
常见错误和坑点
实际调试中最容易栽在这几处：
AutoResetEvent.Set()被多次快速调用，但只有一个线程被唤醒——因为第二次
Set()发生在第一次唤醒+自动
Reset()之前，信号被“覆盖”了 忘记给
ManualResetEvent调用
Reset()，导致后续测试中
WaitOne()总是秒过，行为不可复现 在
using块里创建事件对象，但没
Dispose()—— 这俩都实现了
IDisposable，长期运行的服务必须释放句柄，否则泄漏内核对象 把
WaitOne()放在 UI 线程（如 WinForms/WPF）且不加超时，一旦漏掉
Set()，整个界面就卡死
var auto = new AutoResetEvent(false);
var manual = new ManualResetEvent(false);
// 错误示范：没 Dispose
Task.Run(() => {
auto.WaitOne(); // 等信号
Console.WriteLine("auto done");
});
// 正确做法（尤其服务端）
try
{
if (auto.WaitOne(5000)) // 加超时
Console.WriteLine("auto done");
else
Console.WriteLine("timeout");
}
finally
{
auto.Dispose(); // 必须释放
}
ManualResetEvent 和 AutoResetEvent 的本质区别不在“谁更高级”，而在“谁负责重置”。用错不是报错，而是逻辑静默失效——线程该等不等、该停不停，这种 bug 往往要压测几天才暴露。 
