Go标准库无HTTP限流能力，需用golang.org/x/time/rate（令牌桶）或go.uber.org/ratelimit（漏桶）；全局/用户级限流需注意并发安全、路径放行、响应头规范及业务语义复合key设计。
Go 标准库本身不提供 HTTP 请求限流能力，必须借助第三方库或手动封装；直接在 http.Handler 层做限流最稳妥，避免绕过中间件逻辑。
用 golang.org/x/time/rate 实现每秒请求数（QPS）限制
这是 Go 官方维护的令牌桶实现，轻量、无依赖、线程安全。核心是 rate.Limiter，它需要两个参数：每秒最大许可数（limit）和初始令牌数（borrow，通常等于 limit）。
常见错误是把 limit 设为 0 或负数，会导致 Allow() 永远返回 false；另一个坑是复用同一个 rate.Limiter 实例却没考虑并发竞争——其实它本身就是并发安全的，无需额外加锁。
- 对全站统一限流：在全局声明一个
var globalLimiter = rate.NewLimiter(10, 10) - 对用户维度限流：用
map[string]*rate.Limiter+sync.RWMutex缓存，key 为r.RemoteAddr或解析出的X-Forwarded-For - 注意：如果使用
net/http.ServeMux，需确保限流逻辑在http.HandlerFunc内部调用limiter.Allow()，而不是在http.ListenAndServe前就判断
在 Gin 中集成限流中间件时要注意请求路径匹配粒度
Gin 的中间件执行顺序和路由分组会影响限流生效范围。比如把限流中间件注册在 router.Use() 全局链里，所有路由都会被限制；但如果注册在某个 router.Group("/api") 下，则只作用于该前缀。
立即学习“go语言免费学习笔记（深入）”；
容易忽略的是静态文件、健康检查接口（如 /healthz）也被限流，导致监控误报。建议用 if path == "/healthz" { c.Next(); return } 显式放行。
- 不要在中间件里直接
c.AbortWithStatus(429)后返回，应调用c.Abort()防止后续 handler 执行 - 响应头建议加上
X-RateLimit-Limit和X-RateLimit-Remaining，可用limiter.Limit()和limiter.Burst()推算，但注意剩余令牌数需通过limiter.ReserveN(time.Now(), 1)获取更准确值 - 若用 Gin v1.9+，可配合
c.Request.Context()传递限流结果，供下游日志或审计使用
uber-go/ratelimit 和 go.uber.org/ratelimit 的关键区别
这两个包名字相似但完全无关：go.uber.org/ratelimit 是 Uber 维护的单机漏桶实现（无令牌桶），而 uber-go/ratelimit 是旧版已归档仓库，文档和示例都指向前者。当前推荐用 go.uber.org/ratelimit，它的 Take() 方法会阻塞直到可执行，适合后台任务；而标准库 rate.Limiter 的 Allow() 是非阻塞的，更适合 HTTP 接口快速失败。
- 如果你需要“等一等再处理”，选
go.uber.org/ratelimit - 如果你要“超了就 429”，选
golang.org/x/time/rate - 两者都不支持分布式限流，跨进程/多实例部署时必须搭配 Redis + Lua（如
github.com/go-redis/redis/v9的Eval）
真正难的是限流策略与业务语义对齐：同一个用户发 100 次 /login 是攻击，但发 100 次 /callback?token=xxx 可能是合法重试。别只看 IP 或路径，得结合 query 参数、header、甚至 JWT payload 做复合 key。这点几乎没人写进 demo，但线上出问题基本都栽在这儿。
