countdownevent 初始化必须指定正整数计数值，任务数应等于初始计数值；signal() 线程安全且需在 finally 中调用以防异常漏发；wait() 无 await 版本，不支持 async/await 原生等待。
CountdownEvent 初始化时必须指定初始计数值
创建 CountdownEvent 实例时，必须传入一个正整数作为初始计数，它代表“还需等待多少次 Signal() 才能触发完成”。传 0 会直接进入终止状态（IsSet == true），后续调用 Wait() 会立即返回，但容易让人误以为“还没开始就结束了”。
常见错误是把任务数量和计数值搞反：比如启动 5 个异步操作，却初始化为 new CountdownEvent(4)，导致少等一次信号就提前唤醒；或初始化为 new CountdownEvent(6)，最后一直阻塞超时。
- 正确做法：任务数 = 初始计数值，例如
var cde = new CountdownEvent(5) - 若需动态调整（如中途取消某个任务），可用
cde.AddCount(1)或cde.Signal(-1)，但要注意线程安全和负值限制 - 不建议复用已触发的
CountdownEvent，应新建实例
Wait() 阻塞等待直到计数归零，支持超时和取消
Wait() 是核心同步点，它会阻塞当前线程（或 async 等价物）直到内部计数变为 0。它不是轮询，底层基于内核事件对象，效率高。
务必注意：没有 await 版本的 Wait() —— CountdownEvent 是同步类型，不支持原生 async/await。若在 async 方法中使用，应包裹在 Task.Run(() => cde.Wait()) 中，但要警惕线程池开销；更推荐搭配 CancellationToken 使用以支持及时中断。
- 带超时：
cde.Wait(TimeSpan.FromSeconds(3))返回false表示超时未完成 - 带取消：
cde.Wait(ct)，其中ct是CancellationToken，触发后抛OperationCanceledException - 不要在 UI 线程直接调用
Wait()（尤其无超时），否则界面冻结
Signal() 减少计数，多线程调用安全
Signal() 是线程安全的原子操作，每次调用使内部计数减 1。多个线程可并发调用，无需额外锁。这是它比手动维护 int 计数 + lock 更可靠的关键原因。
典型场景是在每个异步任务结束时调用，例如 Task.Run(() => { DoWork(); cde.Signal(); })。但要注意：如果任务抛出异常未捕获，Signal() 就不会执行，导致计数永远不归零 —— 这是最常见的挂起原因。
- 务必确保每个分支（包括
catch和finally）都调用Signal()，或统一放在finally块里 - 可传参
Signal(2)一次性减去多个值，适用于一个任务代表多个子单元完成的情况 - 调用
Signal()超过初始计数值不会报错，但计数会变成负数（CurrentCount可为负），IsSet仍为true
CountdownEvent 不适合替代 Task.WhenAll 或 ManualResetEventSlim
它解决的是“等待 N 次独立信号”的问题，不是“等待所有 Task 完成”或“单次广播通知”。混淆用途会导致代码难维护甚至死锁。
例如，用 CountdownEvent 等待 10 个 Task，却在 Task.ContinueWith 里调用 Signal()，若 ContinueWith 调度失败或被取消，信号就丢失；而 Task.WhenAll(tasks).Wait() 是语义明确、自带错误传播的方案。
- 优先用
Task.WhenAll处理已知数量的Task - 用
ManualResetEventSlim实现“单次唤醒多个等待者” -
CountdownEvent的真实优势场景：工作项由不同线程/模块动态注册并完成（如 IOCP 回调、事件处理器、插件系统），无法预建Task列表
Signal()，以及误以为它支持 async 等待。这两个点一旦出错，调试时往往表现为“程序卡住不动”，且无明显异常堆栈。 
