Iris 不支持开箱即用的自适应并发控制，需手动集成外部指标与限流策略；必须解耦异步采样与同步限流，避免中间件中实时系统调用或远程查询拖慢请求。
Iris 本身不提供开箱即用的「自适应并发控制」机制，所谓自适应（比如根据 CPU 使用率、请求延迟或队列积压动态调速），必须由你手动集成外部信号源 + 限流策略组合实现。硬编码固定 QPS 的 golang.org/x/time/rate.Limiter 或 Redis Lua 计数器只是静态限流，离“自适应”还差一层反馈闭环。
为什么不能只靠 iris.Use() 注册一个中间件就搞定
常见误解是写个中间件读取 runtime.NumGoroutine() 或 cpu.Percent() 然后简单 if 判断——这会严重拖慢每个请求路径：采样本身有开销，且指标滞后、粒度粗（整进程级），无法反映单个 API 路由的真实压力。更关键的是，Iris 中间件链是同步执行的，你在中间件里做耗时采样或远程指标拉取，等于给所有请求加了统一延迟。
- 不要在中间件里实时调用
cpu.Percent(0)—— 它底层是阻塞式系统调用，高并发下直接成为瓶颈 - 避免每请求都查 Prometheus / VictoriaMetrics —— HTTP roundtrip 延迟不可控，且易触发雪崩
- 不推荐用
sync.Map存储各路由的近期 p95 延迟并据此调整速率——缺乏跨进程一致性，且 Map 迭代本身有锁竞争
生产可用的自适应方案：指标采集与限流解耦
核心思路是把「指标观测」和「限流决策」拆到不同阶段：前者异步低频采样并写入共享存储（如 Redis Hash），后者在请求入口快速读取最新快照值做判断。这样既保证实时性，又不污染主请求链路。
- 用 goroutine 每 2 秒拉一次本机
/proc/stat和 Iris 内置的app.GetAppInfo()中的活跃连接数、最近 10s 平均延迟，聚合为api:/users/{id}:cpu=42,latency_p95=182写入 Redis，过期设为 10 秒 - 限流中间件改用 Lua 脚本原子读取该 key，若
latency_p95 > 200则自动把窗口内允许请求数降为原值的 50%；若cpu 且延迟稳定，则逐步回升至上限 - 注意：Redis 的
HGETALL在 key 字段多时性能下降明显，建议按路由路径哈希分片，例如存成metrics:users:shard_2
如何让单个 API 路由独立响应变化
全局自适应容易误伤低负载接口。真实场景中，/auth/login 和 /api/report/export 的流量特征天差地别，必须支持 per-route 策略。Iris 的 Party 分组机制正好用来隔离配置：
- 为高敏路由单独建
authGroup := app.Party("/auth")，注册专属中间件AdaptiveRateLimiter(authCfg)，其配置从环境变量或 Consul 动态加载 - 在中间件初始化时，用
redisClient.SetNX(ctx, "rate:config:/auth/login", `{"base_qps":100,"scale_factor":0.7}`, 5*time.Minute)设置基础参数，后续仅更新因子 - 关键点：不要在
ctx.Path()上做字符串匹配来选策略——Iris 的路由参数（如/users/{id:int}）会导致每次 path 不同，应提前在ConfigureHost阶段注册路由元信息映射表
最易被忽略的是「自适应阈值漂移」：当服务刚启动或突发流量退去后，CPU 和延迟指标恢复需要时间，但限流策略若立即放开，可能引发二次冲击。务必在升降速逻辑里加入最小维持窗口（如至少保持 30 秒当前限流强度），否则你会看到 QPS 曲线像心电图一样剧烈抖动。
