不能直接在 handler 里 new rate.Limiter，因为每个请求新建实例导致独立令牌桶、限流失效；正确做法是用 sync.Map 按清洗后的路径（如 /v1/user/profile）分桶，为不同接口配置差异化策略，如登录接口宽松（rate.Every(200ms),10）、密码重置严格（rate.Every(5s),1），并统一使用 Wait() 或 Allow() 避免行为不一致。
为什么不能直接在 handler 里 new rate.Limiter
因为每个请求都新建一个 rate.Limiter，相当于每请求配一个独立桶，完全失去限流意义——桶永远满的，限流逻辑形同虚设。正确做法是复用实例，且按接口路径做隔离。
如何为不同接口配置不同限流策略
别用全局单实例，也别靠 if/else 判断 path 后硬塞同一个 limiter。应该用 sync.Map 按路由路径（如 /v1/user/profile）做 key 分桶：
-
sync.Map存的是map[string]*rate.Limiter，key 是 cleaned path（去掉 query 和 trailing slash） - 初始化时预热常用接口的 limiter，比如
rate.NewLimiter(rate.Every(1*time.Second), 5)表示每秒最多 5 次 - 对高频接口（如登录）可设更宽松策略：
rate.NewLimiter(rate.Every(200*time.Millisecond), 10)（即每 200ms 放 1 个，允许突发 10） - 对敏感接口（如密码重置）必须严格：
rate.NewLimiter(rate.Every(5*time.Second), 1)
Wait() 和 Allow() 在阶梯控制中怎么选
阶梯式控制本质是“不同路径、不同容忍度”，不是单纯拒绝或排队。关键看行为语义：
- 用
limiter.Wait(c.Request.Context())：适合允许短时排队的接口（如查询类），但必须传入 context，否则超时失效 - 用
limiter.Allow()：适合硬性拒绝场景（如写操作），立刻返回429，不阻塞 goroutine - 千万别混用：同一路径下不要一部分用
Wait()、一部分用Allow()，会导致行为不一致
为什么按 IP 或用户 ID 分桶反而破坏阶梯设计
阶梯控制的对象是「接口」，不是「人」。按 user_id 或 c.ClientIP() 分桶会把限流粒度从路径下沉到调用方，导致：
立即学习“go语言免费学习笔记（深入）”；
- 同一接口对不同用户生效不同策略，运维无法统一评估容量
- 缓存 key 爆炸（
user_id + path组合远多于纯 path） - 无法做接口级水位监控和告警
- 若需用户维度控制，应单独加一层鉴权中间件，与阶梯限流解耦
真正容易被忽略的是：路径清洗逻辑。没 strip query 参数或 normalize path（如 /api/users/ 和 /api/users 被视为两个 key），会导致同一个接口被拆成多个桶，限流失效。
