golang.org/x/time/rate 不支持自适应限流，因 rate.Limiter 的 rate 和 burst 字段不可动态修改；安全做法是用 atomic.Value 原子替换新 Limiter 实例，并建议 burst 与 rate 同比例缩放。
用 golang.org/x/time/rate 做不了自适应限流
它只支持固定 Limiter，所有 Allow、Reserve 行为都基于预设的 rate.Limit 和 burst。系统负载变化时，你没法在运行时安全地“改”它的速率——内部字段未导出，强行反射替换会破坏令牌桶一致性。
真正能动的路子只有两个：自己实现带状态更新的限流器，或者换用支持动态配置的第三方库（比如 uber-go/ratelimit 的变体或 go-control-plane/envoy/contrib/ratelimit 的轻量封装）。
用 atomic.Value 安全切换限流器实例
最轻量又线程安全的做法：把整个 *rate.Limiter 实例用 atomic.Value 包一层，每次负载变化时生成新实例并原子替换。调用方始终从 atomic.Value.Load() 拿最新实例，完全不感知切换过程。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 别直接修改旧
Limiter的字段——它不是设计来被改的 - 新
Limiter的burst建议不低于旧值，否则瞬时请求可能全被拒 - 切换频率不宜过高（比如每秒多次），避免频繁 GC 和锁竞争；推荐按 5–30 秒粒度更新
- 示例关键片段：
var limiter atomic.Value limiter.Store(rate.NewLimiter(rate.Every(100*time.Millisecond), 10)) // 负载升高时 newLimiter := rate.NewLimiter(rate.Every(50*time.Millisecond), 20) limiter.Store(newLimiter)
怎么获取靠谱的系统负载信号
CPU 使用率最常用，但单看 /proc/stat 或 runtime.NumCPU() 不够——Go 程序可能跑在容器里，宿主机 CPU 负载和容器内实际压力不一致。更稳的是组合信号：
立即学习“go语言免费学习笔记（深入）”；
- 用
github.com/shirou/gopsutil/v3/cpu.CPUPercent读容器 cgroup 的cpu.stat（需挂载/sys/fs/cgroup） - 加一个简单的请求延迟移动平均（比如最近 100 次
http.Handler耗时的 P95），延迟突增说明服务已吃紧 - 避免用内存使用率做主信号——Go 的 GC 周期会让 RSS 波动剧烈，容易误触发
- 阈值别设死：比如 CPU > 70% 就降速，不如用「当前值 / 近 5 分钟均值 > 1.5」这类相对判断
注意 rate.Limiter 的 burst 语义陷阱
很多人以为 burst 是“并发数上限”，其实它是“允许透支的令牌数”。如果设置 burst=5 且速率是每秒 10 个，那瞬间打进来 15 个请求不会全拦，前 5 个立刻放行，后 10 个按 100ms 间隔放——这在高负载下调小 burst 反而会导致请求堆积更严重。
- 自适应时，建议
burst和rate同比例缩放（比如都 ×0.6），而不是只调 rate - 若业务对突发敏感（如支付接口），可额外加一层
sync.Pool缓存的计数器，在Allow前快速拦截超限并发 - 别依赖
Wait的超时逻辑做限流兜底——它会阻塞 goroutine，高负载下可能拖垮调度器
