rate.Limiter不能直接用于自适应限流，因其是纯前馈型静态组件，初始化后按固定rate和burst机械放行，完全不感知下游延迟飙升、GC暂停、P95响应恶化等实时负载变化，导致过载时仍持续放行引发超时雪崩。
自适应限流不能靠 golang.org/x/time/rate.Limiter 初始化后一劳永逸，它本身没有反馈能力；必须叠加实时指标采集 + 动态阈值调节逻辑，否则系统过载时还在机械放行。
为什么 rate.Limiter 直接用不了自适应
rate.Limiter 是纯前馈型组件：你传入 rate.Limit(100) 和 burst=50，它就永远按这个节奏吐令牌，不管下游 DB 是否延迟飙升、GC 是否频繁暂停、P95 响应是否从 20ms 涨到 800ms。常见错误现象是——QPS 没超阈值，但大量请求超时或失败，而限流器毫无反应。
- 它不感知任何运行时指标（延迟、错误率、并发数）
- 旧版本 Go（Limit，只能重建实例
- 即使新版支持
SetLimit()，也得你自己写调节器，它只负责“执行”，不负责“判断”
核心指标必须本地采集，别依赖外部监控
自适应的前提是低延迟反馈闭环。等 Prometheus 抓一次指标再调限流阈值，已经晚了。真实可行的指标只有三类，且必须进程内原子采集：
-
P90或P95请求延迟：用滑动窗口（如 10 秒分 100 桶）+atomic.Int64计数，避免锁 - 失败率：用两个
atomic.Int64分别记成功/失败总数，每秒算比值（注意除零） - 当前活跃 goroutine 数：直接读
runtime.NumGoroutine()，成本极低
别把指标存在 c.Request.Context() 里——生命周期仅单次请求，跨请求无法聚合；也别用 sync.Map 存延迟直方图，高频写会成瓶颈。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
调节逻辑要分场景，不能一刀切降 QPS
不同过载信号对应不同响应强度，硬砍 50% 可能误伤正常流量。示例调节策略（基于每秒检查）：
- 若
P95 > 300ms且失败率< 5%→ 可能是资源争抢，保守降 10%：newLimit = int64(float64(old) * 0.9) - 若失败率
> 10%→ 已出现雪崩苗头，激进降 50%，并设最低保护值（如maxInt64(5, newLimit)） - 若并发数
> 500且延迟未明显升高 → 可能是 CPU 密集型任务堆积，优先降并发允许量，而非 QPS
调节后必须调用 limiter.SetLimit(rate.Limit(newLimit))（Go 1.21+），旧版本需用 atomic.StorePointer 替换 limiter 指针，避免中间件里出现 nil 指针 panic。
并发安全的关键细节容易被忽略
整个自适应链路里，最脆弱的是“指标采集 → 判断 → 调节 → 生效”这四步的竞态。常见坑点：
- 不要在 HTTP handler 里直接调
time.Sleep()或长耗时采集，会阻塞 goroutine - 调节器（adjust goroutine）和 handler 共享 limiter 实例时，
SetLimit()是线程安全的，但你要确保它不被并发多次调用（加sync.Once或时间间隔控制） - 滑动窗口统计延迟时，桶索引计算必须用
time.Now().Truncate(shardDur)对齐起点，否则窗口跳变导致数据错位
真正难的不是写调节公式，而是让指标采集、阈值更新、请求放行三者在高并发下不互相干扰——多数线上问题都出在这里，而不是算法本身。
