必须用 SemaphoreSlim 的 WaitAsync() 和 finally 中的 Release() 配对控制并发，lock/Monitor 会阻塞线程池，不适用于 I/O 并发控制；需按资源隔离实例，上限依据下游承载力设定。
直接说结论：用 SemaphoreSlim 控制并发数，必须配对 WaitAsync() 和 Release()，且 Release() 一定要放在 finally 块里——漏一次，后续所有等待就永久卡住。
为什么不能用 lock 或 Monitor 替代 SemaphoreSlim
它们是同步原语，lock 会把线程池线程卡死在等待队列里，而你真正要控的是「同时发出去的请求数」或「同时执行的 I/O 操作数」，不是「谁先抢到 CPU 时间片」。比如发起 1000 个 HTTP 请求，用 lock 会导致线程池快速耗尽，响应延迟飙升；SemaphoreSlim 的 WaitAsync() 是异步挂起，不占线程，这才是匹配 async/await 的正确姿势。
-
lock和Monitor适合保护内存共享变量（如静态计数器），不适合控制资源访问节奏 -
SemaphoreSlim初始化时传入的数字是硬上限，比如new SemaphoreSlim(4)表示最多 4 个WaitAsync()能立刻返回，第 5 个必须等前面有人Release() - 它不依赖操作系统内核对象，比老式
Semaphore开销低，尤其适合高吞吐 Web API
WaitAsync() 必须配 finally 中的 Release()
这是最常踩的坑：异常一抛，Release() 就没机会执行，许可数永远少一个。哪怕 WaitAsync() 成功了，后续操作（比如 HttpClient.SendAsync()）抛出 HttpRequestException，也得确保释放。
- 写法必须是：
await semaphore.WaitAsync(); try { /* 实际操作 */ } finally { semaphore.Release(); } - 不要用
using包裹SemaphoreSlim——它不是IDisposable资源型对象，Dispose()只清理内部 Task 状态，不影响计数 - 别在
catch块里Release()：如果WaitAsync()自己超时抛出OperationCanceledException，说明根本没拿到许可，此时调Release()会触发ObjectDisposedException或计数错乱
如何为不同资源设置独立的 SemaphoreSlim 实例
一个 SemaphoreSlim 实例只能管一类资源。混用会导致逻辑耦合、调试困难，比如用同一个实例既控数据库连接又控日志写入，某次日志慢了会拖垮整个订单处理流程。
- 按资源边界隔离：数据库操作用
_dbSemaphore = new SemaphoreSlim(10)，外部 API 调用用_apiSemaphore = new SemaphoreSlim(5) - 初始化
maxCount要参考下游实际承载力：数据库连接池默认是 100，设成 15～20 较安全；API 限流常见是 3～10，避免被 429 拒绝 - 不要盲目设成 CPU 核心数：I/O 密集型场景（HTTP、DB）的并发瓶颈不在 CPU，而在网络带宽、连接池或远端服务响应能力
SemaphoreSlim 不保证执行顺序，也不防重入
它只管“有多少个能进”，不管“谁先进”。默认是非公平的，高并发下可能让后请求的线程先拿到许可。另外，同一线程可以连续调用多次 WaitAsync()（即支持重入），但每次都要对应一次 Release()，否则照样泄漏。
- 如果你需要严格 FIFO，得自己加队列 +
TaskCompletionSource手动排队，SemaphoreSlim不提供该能力 - 重入场景真实存在：比如某个服务方法内部调用了另一个也受同一信号量保护的方法，这时要小心嵌套等待导致的死锁风险
- 性能上，
SemaphoreSlim在千级并发下依然高效，但若单次WaitAsync()平均等待时间超过 100ms，说明设定的并发数过小，该调大了
真正难的不是写对那几行代码，而是想清楚「这个信号量到底在保护什么资源」「它的上限是由哪一方决定的」——是数据库连接池？是第三方 API 的配额？还是你自己服务器的内存水位？定错边界，再严谨的 Release() 也救不了架构问题。
