因为 lock 是同步阻塞的，不支持 await，易导致死锁或线程池饥饿；应使用 semaphoreslim(1,1) 配合 waitasync() 和 try/finally 中的 release() 实现异步互斥。
为什么不能直接用 lock 做异步等待
因为 lock 是同步阻塞的，底层调用的是 Monitor.Enter，它不支持 await。如果你在 async 方法里写 lock，编译器会警告“不能在异步方法中使用同步锁”，更严重的是：一旦锁被其他线程长时间持有，当前 await 后续的上下文可能被挂起，导致死锁或线程池饥饿。
真正需要异步等待锁的场景，比如：多个 http 请求并发写入同一个共享缓存、批量任务争抢有限的外部资源配额（如 API 调用次数）、或避免 ui 线程被阻塞。
SemaphoreSlim.WaitAsync() 的正确用法
这是 C# 中最常用、也是官方推荐的异步锁方案。它不是“互斥锁”而是“计数信号量”，但把初始计数设为 1 就等效于异步互斥锁。
- 初始化：
var semaphore = new SemaphoreSlim(1, 1); - 等待锁：
await semaphore.WaitAsync();—— 可带CancellationToken，支持超时：await semaphore.WaitAsync(TimeSpan.FromSeconds(3)); - 释放锁：
semaphore.Release();（注意：不是await，它是同步的） - 必须确保
Release()总被执行，建议用try/finally包裹
错误示范：await using 不适用，因为 SemaphoreSlim 不实现 IAsyncDisposable；也不要漏掉 finally，否则锁永远无法释放。
常见坑：重复释放、跨 await 释放、未处理取消
SemaphoreSlim.Release() 被调用次数超过 WaitAsync() 成功次数，会抛出 InvalidOperationException：“释放次数超过获取次数”。这通常发生在：
- 多个
await后误写两次Release() - 在
catch和finally里都写了Release() - 用了
using语句块但没注意Dispose()不等于Release()
另外，WaitAsync() 支持 CancellationToken，但如果你传入的 token 已触发取消，它会抛 OperationCanceledException，此时锁根本没拿到，Release() 绝对不能执行。
替代方案对比：AsyncLock 封装是否必要
有人封装 AsyncLock 类（内部用 SemaphoreSlim），提供 LockAsync() + using 语义。它确实让代码更简洁，比如：
await using (await _asyncLock.LockAsync()) { // 临界区 }但要注意：这个 await using 的生命周期依赖于 IDisposable 实现，而真正的释放动作仍在 Dispose() 中调用 Release()。如果临界区抛异常且未被捕获，Dispose() 仍会执行——这是安全的；但如果封装类没正确处理重入或取消逻辑，反而增加隐蔽风险。
对大多数项目，直接用裸 SemaphoreSlim + try/finally 更透明、更可控。复杂业务才考虑封装，且务必覆盖取消和异常路径测试。
最易被忽略的一点：信号量是进程内同步原语，跨进程或分布式场景下完全无效，这时候得换 redis 或数据库行锁。