直接用 golang.org/x/time/rate，它基于线程安全的 token bucket，经高并发验证，且与主流框架天然兼容；自行实现易出并发问题。
Go 限速器用 golang.org/x/time/rate 还是自己写？
直接用 golang.org/x/time/rate，别自己造轮子。它基于 token bucket 实现，线程安全，已通过高并发压测验证，且和 net/http、gin、echo 等框架天然兼容。自己实现容易在并发场景下漏桶、误判或 panic。
注意两个关键点：
-
rate.Limiter的limit参数单位是「每秒令牌数」，不是「每分钟」或「每次请求」，传10表示每秒最多放行 10 次请求 -
burst必须 ≥limit，否则初始化会 panic；它代表桶容量，也决定了突发流量能被接受的峰值（例如limit=5, burst=20允许短时 20 次请求，之后按 5qps 匀速恢复）
HTTP 中间件里怎么加限速？以 Gin 为例
在 Gin 中最稳妥的方式是用 gin.HandlerFunc 封装 rate.Limiter，并为不同路由或用户分配独立限速器——避免全局共享导致 A 路由被 B 用户拖垮。
常见错误：把同一个 rate.Limiter 实例复用于所有请求，结果 /health 和 /pay 接口共用一套令牌，健康检查失败连带支付接口被限流。
立即学习“go语言免费学习笔记（深入）”；
func RateLimitMiddleware(limiter *rate.Limiter) gin.HandlerFunc {
return func(c *gin.Context) {
if !limiter.Allow() {
c.Header("X-RateLimit-Remaining", "0")
c.AbortWithStatusJSON(http.StatusTooManyRequests, map[string]string{
"error": "rate limit exceeded",
})
return
}
c.Next()
}
}
// 使用示例：给 /api/v1/users/ 下所有接口配独立限速器
userLimiter := rate.NewLimiter(rate.Every( time.Second/5 ), 5) // 5qps
r.GET("/api/v1/users/*path", RateLimitMiddleware(userLimiter), userHandler)
如何按用户 ID 或 IP 做差异化限速？
不能靠单个全局限速器，得用 sync.Map 或第三方缓存（如 ristretto）做 key → limiter 映射。key 选 userID 或 c.ClientIP()，但要注意：ClientIP() 在有反向代理时可能取到的是 LB 的 IP，需配合 X-Forwarded-For 解析真实 IP 并清洗。
性能敏感点：频繁新建 rate.Limiter 实例开销大，应复用；但也不能无限缓存，需加 TTL 清理闲置限速器（比如 10 分钟无请求则删除）。
- 用
sync.Map存储时，key 是字符串（如"ip:192.168.1.100"），value 是*rate.Limiter - 调用
AllowN(time.Now(), n)可支持批量请求（如上传文件分片），n > 1 时需确保 burst ≥ n - 别在限速逻辑里做 DB 查询或 HTTP 调用，否则延迟放大、限速失效
微服务间 gRPC 调用怎么限速？
gRPC 本身不内置限速，得在服务端拦截器（UnaryServerInterceptor）中注入限速逻辑。和 HTTP 类似，但要注意：context.Context 生命周期更短，且 gRPC 默认不透传 HTTP 头，所以无法直接复用基于 header 的用户标识，得从 metadata.MD 里取 user_id 或 app_id。
典型坑：
- 在拦截器里 new 一个 limiter 但没做 key 分组，导致整个服务共用一个桶
- 用
time.Now()判断超时时未考虑 gRPC 流式调用的长连接特性，造成误限 - 限速返回
status.Error(codes.ResourceExhausted, "...")，客户端必须处理该 code，否则可能重试风暴
真正难的不是加限速，而是限速阈值怎么定：得结合链路追踪（如 Jaeger）看 P95 延迟、上游依赖水位、以及业务 SLA 综合评估。硬编码 100qps 很容易在大促时崩掉，也容易在低峰期过度限流。
