直接用 golang.org/x/time/rate。它是官方维护的生产级令牌桶实现，基于原子操作和单调时钟，支持 rate.Limit 和 burst 参数，避免自行实现的并发安全、时钟漂移等问题。
Go 限流该用 golang.org/x/time/rate 还是自己写令牌桶？
直接用 golang.org/x/time/rate。它就是 Go 官方维护的、生产级令牌桶实现，不是玩具库。自己手撸容易漏掉并发安全、时钟漂移、burst 精确控制等细节，反而引入 bug。
核心类型是 rate.Limiter，底层基于原子操作和单调时钟，支持每秒多少请求（rate.Limit）和最大突发量（burst）两个参数：
limiter := rate.NewLimiter(rate.Every(100*time.Millisecond), 5) // 每 100ms 放行 1 个，最多积压 5 个
注意：burst 必须 ≥ 1，设为 0 会 panic；rate.Every 是推荐写法，比手动算 rate.Limit(10) 更直观。
HTTP 中间件里怎么嵌入限流逻辑？
在 http.Handler 链中加一层中间件最自然。关键点是：每个路由/用户/IP 是否共用一个限流器？通常按维度隔离，避免全局锁或误伤。
立即学习“go语言免费学习笔记（深入）”；
- 全站统一限流：单例
rate.Limiter，最简单，适合后台管理接口 - 按 IP 限流：用
net.ParseIP(r.RemoteAddr)提取 IP，查 map 或 sync.Map 缓存限流器（避免高频 new） - 按用户 ID（如 JWT 中的
sub）：解析 token 后做 key，注意 token 失效时清理缓存
示例（IP 维度）：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var ipLimiters sync.Map // map[string]*rate.Limiter
func limitByIP(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ip := net.ParseIP(r.RemoteAddr[:strings.LastIndex(r.RemoteAddr, ":")])
key := ip.String()
limiter, _ := ipLimiters.LoadOrStore(key, rate.NewLimiter(rate.Limit(10), 5))
if !limiter.(*rate.Limiter).Allow() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
Allow() 和 Wait() 在 Web 场景下怎么选？
Web 请求必须用 Allow() 或带超时的 WaitN(ctx, n, timeout)，绝不能用无超时的 Wait() —— 它可能永久阻塞 goroutine，拖垮整个服务。
-
Allow()：非阻塞，立刻返回 bool，适合“拒绝即走”策略（如返回 429） -
WaitN(ctx, 1, 100*time.Millisecond)：最多等 100ms，超时就拒绝，适合想给点缓冲但不卡住的场景 - 别用
Reserve()手动判断再Delay()：易出竞态，且延迟逻辑需手动注入 response 流程，难维护
注意：WaitN 的 ctx 要带 deadline，否则和 Wait 一样危险。
为什么加了限流，Prometheus 指标还是不准？
因为 rate.Limiter 本身不暴露计数器。要打点，得在中间件里自己埋点：
- 每次调用
Allow()前 +1http_requests_total{status="allowed"} - 拒绝时 +1
http_requests_total{status="rejected"} - 如果用了 per-IP 限流，还可加
rate_limiter_burst_used{ip="1.2.3.4"}（需反射读lim.Burst()和当前剩余令牌数，较重）
更轻量的做法是只统计拒绝率：它能真实反映限流生效强度。突增的 429 比 “平均令牌消耗” 更有运维价值。
别忘了限流器初始化位置——放错地方（比如 handler 内部每次新建）会导致限流完全失效。
