为什么不能直接用 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或数据库行锁。
