不能直接用 SemaphoreSlim 包裹 HttpClient.SendAsync，因为 HttpClient 自带连接池并发控制，盲目加锁会掩盖真实瓶颈、引发死锁；应将信号量置于请求发起前限流并发数，而非执行中阻塞线程。
为什么不能直接用 SemaphoreSlim 包裹 HttpClient.SendAsync
很多人第一反应是：在每次请求前 await semaphore.WaitAsync()，结束后 semaphore.Release()。这看似合理，但会出问题——HttpClient 本身是线程安全的，且底层连接池（HttpConnectionPool）已自带并发控制（如 MaxConnectionsPerServer）。盲目加 SemaphoreSlim 只是在应用层叠一层锁，容易掩盖真实瓶颈，还可能因异常未释放导致死锁。
真正该限制的是「发起请求的节奏」，不是「执行请求的线程」
你真正想控的是单位时间内发出去的请求数（比如防止压垮下游 API），而不是阻塞线程等待连接可用。这时应把 SemaphoreSlim 放在「请求构造完成、准备调用 SendAsync 之前」，确保并发发起数不超限。
-
SemaphoreSlim初始化时传入最大并发数，比如new SemaphoreSlim(5) - 每个请求前
await semaphore.WaitAsync(cancellationToken)，注意务必传入CancellationToken防止取消丢失 - 必须用
try/finally或using确保Release()被调用，哪怕请求抛异常或超时 - 不要在
HttpClient实例上做任何同步阻塞操作（如.Result），否则会拖垮SemaphoreSlim的异步信号量逻辑
一个安全可用的封装示例
public class LimitedHttpClient
{
private readonly HttpClient _client;
private readonly SemaphoreSlim _semaphore;
public LimitedHttpClient(HttpClient client, int maxConcurrency)
{
_client = client ?? throw new ArgumentNullException(nameof(client));
_semaphore = new SemaphoreSlim(maxConcurrency, maxConcurrency);
}
public async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken = default)
{
await _semaphore.WaitAsync(cancellationToken).ConfigureAwait(false);
try
{
return await _client.SendAsync(request, cancellationToken).ConfigureAwait(false);
}
finally
{
_semaphore.Release();
}
}
}
用法：var response = await limitedClient.SendAsync(req, ct);。关键点：释放必须在 finally 中，且不参与 await（Release() 是同步的）。
比 SemaphoreSlim 更合适的替代方案
如果目标是「稳定限流 + 自动重试 + 超时熔断」，SemaphoreSlim 就太原始了。推荐组合使用：
-
Microsoft.Extensions.Http.Polly+RateLimitPolicy：基于时间窗口的精确 QPS 控制 -
System.Threading.RateLimiting（.NET 7+）：原生RateLimiter类型，支持滑动窗口、令牌桶等策略，且线程安全、无内存泄漏风险 - 若只是临时压测节流，
SemaphoreSlim能用，但别把它当成生产级限流方案——它不感知响应延迟、不自动退避、不记录指标
真正上线前，得确认下游接口的 SLA 和你本地的 HttpClient.Timeout、MaxConnectionsPerServer 是否匹配；否则限流了，连接池却卡在 ConnectPending 状态，照样雪崩。
