Semaphore不能直接await，因其是.NET Framework 1.1的同步原语，无WaitAsync方法；需异步限流时应使用SemaphoreSlim，它支持WaitAsync、取消令牌且轻量高效。
为什么 Semaphore 不能直接 await？
因为 Semaphore 是 .NET Framework 1.1 就存在的同步原语，它本身不提供异步等待方法。你写 await semaphore.WaitAsync() 实际调用的是 SemaphoreSlim，不是 Semaphore。混淆这两者是初学者最常踩的坑——Semaphore 没有 WaitAsync 方法，强行调用会编译失败。
正确做法：需要异步控制并发时，必须用 SemaphoreSlim；仅需跨进程同步（比如多个 .exe 互斥访问同一资源），才考虑 Semaphore（且得配命名）。
-
Semaphore：基于操作系统内核对象，支持跨进程，但无 async 支持，性能开销大 -
SemaphoreSlim：纯托管实现，轻量、支持WaitAsync和取消令牌，但仅限当前进程内使用 - 默认构造
new Semaphore(1, 1)不等于“线程安全”——它只限制同时进入的线程数，不保护共享变量本身
如何用 SemaphoreSlim 安全控制 API 调用并发数？
这是最常见的使用场景：防止对下游服务发起过多并发请求。关键不是“加锁”，而是“限流”。SemaphoreSlim 在这里充当一个可配置的并发许可桶。
示例：限制最多 5 个并发 HTTP 请求
private static readonly SemaphoreSlim _apiThrottle = new SemaphoreSlim(5, 5);
public async Task<string> CallExternalApi(string url)
{
await _apiThrottle.WaitAsync(); // 等到有许可
try
{
return await _httpClient.GetStringAsync(url);
}
finally
{
_apiThrottle.Release(); // 必须放行，否则许可永久丢失
}
}
- 构造时两个参数都设为 5：初始许可数 = 最大许可数，避免动态扩容带来的逻辑混乱
-
WaitAsync()可传CancellationToken，配合超时或主动取消（如用户关闭页面） -
Release()必须在finally块里调用——哪怕请求抛异常，也要归还许可，否则信号量会被“锁死” - 不要在循环里反复 new
SemaphoreSlim，它应作为静态字段或单例复用
Semaphore 命名实例怎么跨进程生效？
只有带名字的 Semaphore 才能被其他进程打开。但名字不是随便起的字符串——Windows 对命名信号量有权限和作用域限制，常见失败原因是权限不足或名字被系统拒绝。
正确创建方式：
var security = new SemaphoreSecurity();
security.AddAccessRule(new SemaphoreAccessRule(
new SecurityIdentifier(WellKnownSidType.WorldSid, null),
SemaphoreRights.FullControl,
AccessControlType.Allow));
using var sema = new Semaphore(0, 100, "MyApp.SharedResource", out bool createdNew, security);
- 名字（如
"MyApp.SharedResource"）必须全局唯一，建议带产品/模块前缀 - 必须显式传入
SemaphoreSecurity并授予WorldSid权限，否则其他非管理员进程无法打开 -
createdNew输出参数告诉你是不是首次创建——可用于主进程初始化，子进程只打开 - 不要依赖
Dispose自动释放：进程崩溃时内核对象可能残留，重启后需手动清理或用随机后缀规避冲突
为什么 SemaphoreSlim 的 CurrentCount 值不可靠？
CurrentCount 是只读属性，返回当前剩余许可数，但它不是原子快照——只是取值瞬间的近似值。多线程下读出来就可能过期，**绝不能用来做条件判断或“if (sem.CurrentCount > 0) then Wait()”这类逻辑**。
- 它只适合日志、监控或调试观察，比如记录“当前排队请求数”趋势
- 想实现“尝试获取、不阻塞”，应该用
Wait(0)或WaitAsync(0)，而不是查CurrentCount -
Wait(0)返回false表示没拿到许可，此时可降级或返回错误，这才是安全的非阻塞模式
真正难处理的是超时与取消的组合：WaitAsync(timeoutMs, token) 可能因超时或取消抛出不同异常，需要分别捕获 OperationCanceledException 和 TimeoutException——这点很容易被忽略，结果把取消当成超时处理。
