golang.org/x/time/rate 不能直接做自适应限流，因其 rate.Limiter 是静态配置、不感知下游延迟/错误率/负载变化；需结合滑动窗口统计与动态重建实例，并通过原子指针替换、阻尼调整、上下限约束及安全读写机制实现无感自适应。
为什么 golang.org/x/time/rate 不能直接做自适应限流
因为 rate.Limiter 是静态配置的：你初始化时给它一个固定的 rate.Limit（比如每秒 100 个请求），它就永远按这个速率执行令牌桶逻辑，不感知下游延迟、错误率或系统负载变化。真实服务里，如果后端变慢或开始报错，你还硬顶着 100 QPS 往里塞，只会雪上加霜。
用滑动窗口统计 + 动态调整 rate.Limiter 实例
核心思路是：不改 rate.Limiter 本身，而是定期（比如每秒）根据最近窗口内的实际观测指标（如 P95 延迟、错误率、排队耗时）重新创建一个新的 rate.Limiter 实例，并原子替换旧实例。关键点在于：
- 用
sync/atomic存储指向*rate.Limiter的指针，避免锁竞争 - 滑动窗口用
github.com/beefsack/go-rate或自己基于ringbuffer实现，不要用 map + 定时清理——容易漏统计或误删 - 调整策略要带“阻尼”：比如新计算出的目标速率为 60，但当前是 100，那就只降到 90，下个周期再降，防止抖动放大
- 必须设置下限（如 10 QPS）和上限（如原配置的 120%），否则故障时可能直接归零或无限膨胀
如何安全替换正在运行的限流器
直接赋值 limiter = newLimiter 不够——已有 goroutine 可能刚调用完 limiter.Allow() 就被替换了，下次调用会 panic（nil pointer dereference）。正确做法是：
- 定义结构体封装限流器：
type AdaptiveLimiter struct { limiter *rate.Limiter mu sync.RWMutex } - 读操作用
RLock+ 复制指针：func (a *AdaptiveLimiter) Allow() bool { a.mu.RLock() l := a.limiter a.mu.RUnlock() if l == nil { return false } return l.Allow() } - 写操作用
Lock替换，并在替换前调用l.Stop()（如果用了内部 ticker）
延迟突增时，光降 QPS 不够，还得加排队控制
单纯降低速率只能缓解请求涌入，但如果后端已卡住，新请求进来立刻排队等待，内存和 goroutine 会持续增长。这时需要配合：
- 在
Allow()前检查当前排队长度（可通过rate.Limiter.ReserveN()+.Delay()估算，但注意它不阻塞） - 设置硬性排队超时：
if r := limiter.ReserveN(time.Now(), 1); !r.OK() || r.Delay() > 200*time.Millisecond { return errors.New("too much queuing") } - 更稳妥的做法是把排队逻辑外移到独立 channel，用带缓冲的
chan struct{}控制并发等待数，超出即拒绝
自适应的核心不在算法多 fancy，而在指标采集是否低开销、替换是否无感、降级是否有兜底——这些地方写错一行，线上就变成限流器自己成了瓶颈。
