WaitAsync 是异步等待、不阻塞线程，支持 CancellationToken 和 async 链式调度；Wait 是同步等待、阻塞线程，仅适用于纯同步上下文，不响应即时取消，混用易致死锁或性能下降。
WaitAsync 和 Wait 的本质区别：线程是否被阻塞
WaitAsync 是异步等待，不阻塞当前线程；Wait 是同步等待，会直接阻塞调用线程。这是最根本的差异，决定了你该用哪一个。
- 在
async方法里，必须用WaitAsync—— 否则会卡死线程池，尤其在 ASP.NET Core 或高并发后台任务中极易引发吞吐下降甚至死锁 -
Wait适合纯同步上下文（如控制台主流程、单元测试 setup），但一旦混入await就会出问题：它不能和await共存于同一作用域，也不支持CancellationToken的响应式取消（除非用重载Wait(Int32, CancellationToken)，但仍是阻塞） -
WaitAsync天然支持CancellationToken，且返回Task，可参与 async 链式调度，比如：await semaphore.WaitAsync(ct).ConfigureAwait(false)
为什么 WaitAsync 在高并发下更安全？
因为它的等待是“挂起任务”而非“挂起线程”。当许可不足时，WaitAsync 内部用 TaskCompletionSource 暂停当前 Task，把线程还给线程池；而 Wait 会让线程原地休眠（可能触发内核态等待），白白占用一个线程资源。
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 1000 个并发请求，每个都
Wait3 秒 → 可能瞬间耗尽默认线程池（约 1000 线程），造成后续请求排队或超时 - 同样场景用
WaitAsync→ 实际只占用几十个线程，其余任务处于“挂起”状态，内存开销小、调度灵活 - 注意：
WaitAsync并非零成本 —— 它仍需原子操作维护内部计数器_currentCount，竞争激烈时可能退化为内核等待（如 Windows 下触发WaitForSingleObject）
常见误用：在 lock 或同步方法里调用 WaitAsync
这不会报错，但完全失去异步意义，且容易埋雷：
public void BadExample()
{
// ❌ 错误：在同步方法里 await WaitAsync，编译不过（缺少 async）
// 即使强行改成 async void，也会导致异常无法捕获、生命周期失控
semaphore.WaitAsync().Wait(); // 更糟：.Wait() 强制同步等待，抵消了 WaitAsync 的优势
}
- 不要对
WaitAsync调用.Wait()或.Result—— 这等于把异步转回同步，还多一层死锁风险（尤其在 UI 或 ASP.NET 同步上下文） - 若必须从同步入口进入，优先考虑重构为异步链路；迫不得已才用
WaitAsync(timeoutMs).GetAwaiter().GetResult()，并确保 timeout 设置合理 -
Wait本身可安全用于同步方法，但要注意：它不响应CancellationToken的“即时取消”，只能靠超时参数
性能与兼容性：选 SemaphoreSlim 就别回头用 Semaphore
SemaphoreSlim.WaitAsync 是 .NET 4.5+ 引入的现代方案，而 Semaphore 根本没有 WaitAsync 方法 —— 它是纯内核对象，只支持 WaitOne。
- 如果你需要跨进程同步（如多个 exe 共享资源），只能用
Semaphore，但必须接受无异步、性能低、不能用于 async 方法 -
SemaphoreSlim不支持命名，仅限单进程；但它支持WaitAsync、轻量、可取消、可配置自旋等待（构造时传spinBeforeWait参数） - 别试图混合使用：比如用
SemaphoreSlim发布许可，却用Semaphore.WaitOne等待 —— 它们互不识别，毫无关系
Wait，就像在高速路上突然停车；同步方法里滥用 WaitAsync + .Wait()，等于把电梯改成楼梯再爬上去。信号量本身很简单，难的是让它和你的执行模型对齐。 
