应使用 Microsoft.Extensions.RateLimiting 而非 Polly 实现自适应限流，因其支持动态调整速率、提供 IRateLimiterPolicy 扩展点，并兼容 .NET 7+；Polly 的 RateLimit 策略已弃用且不支持运行时参数更新。
别用 Polly 做自适应限流 —— 它不支持动态调整速率，且官方已弃用 RateLimit 策略。 自 .NET 7 起，Microsoft.Extensions.RateLimiting 是唯一受支持的内置限流方案；Polly 的 RateLimitStrategy 在新版中已被移除，强行引用旧包会导致运行时策略不生效或抛 InvalidOperationException。
为什么 Polly 的 RateLimit 不适合自适应场景
Polly 的限流策略（如 AddRateLimit）只接受静态配置：固定 PermitLimit 和 Window，无法在运行时根据 CPU、响应时间等指标实时更新参数。它本质是“开关式”控制，不是反馈闭环系统。
- 调用
AddRateLimit(new RateLimitOptions { ... })后，所有参数被冻结，后续修改PermitLimit字段无效 - 没有暴露
OnRateLimitExceeded以外的钩子，无法插入监控采集或 PID 计算逻辑 - .NET 8+ 项目若同时引用
Polly和Microsoft.Extensions.Http.Resilience，会因类型冲突导致编译失败或策略静默失效
用 Microsoft.Extensions.RateLimiting 实现自适应限流的核心步骤
必须基于 TokenBucketRateLimiter + 自定义 IRateLimiterPolicy<TKey>，通过重写 AcquireAsync 方法注入动态逻辑。关键不是换算法，而是接管令牌发放前的决策权。
- 继承
RateLimiterPolicy<string>，在AcquireAsync中先读取当前系统指标（如Environment.ProcessorCount、GC.GetTotalMemory(false)或 Prometheus 指标客户端） - 用 PID 公式计算目标
PermitLimit：例如newLimit = Math.Max(1, (int)(baseLimit * (1 - 0.3 * (currentLatencyMs / targetLatencyMs - 1)))) - 每次请求都新建
TokenBucketRateLimiterOptions实例（不可复用），传入动态值；注意TokensPerPeriod和ReplenishmentPeriod也要同步调整 - 务必在
AcquireAsync开头加await Task.Yield()避免同步阻塞中间件管道
容易被忽略的线程安全与性能陷阱
自适应逻辑本身不能成为瓶颈。以下三点出错会导致限流器比没开还慢：
- 不要在
AcquireAsync里直接调用HttpClient.GetAsync获取监控数据 —— 必须用预热好的IAsyncEnumerable<MetricSnapshot>或本地缓存（如MemoryCache每 500ms 刷新一次） - 避免对每个请求都重新计算 PID 输出：用
ConcurrentDictionary<string, double>缓存最近 1 秒的输出值，键为$"{ip}:{endpoint}" -
TokenBucketRateLimiter内部使用Interlocked，但你的自定义策略若在AcquireAsync中用了lock或Monitor.Enter，会彻底破坏高并发下的吞吐量
真正的难点不在公式，而在如何让动态阈值变更不引发抖动 —— 比如 CPU 从 70% 突然跳到 95%，限流阈值不能立刻砍半，得加平滑衰减因子。这点连 Microsoft.Extensions.RateLimiting 的默认实现都没覆盖，得自己在策略里补。
