每次请求都 new rate.limiter 会失效，因每个实例维护独立令牌桶状态，100 并发即 100 个桶各自放行，完全失去限流作用；正确做法是全局复用或按 path/user 等 key 缓存 limiter 实例。
Go语言框架里做接口限流，单靠 rate.Limiter 能扛住单机流量，但生产环境多副本部署下必须搭配分桶策略 + 上下文超时控制 + 路径/用户维度隔离，否则限流形同虚设。
为什么每次请求都 new 一个 rate.Limiter 就失效
常见错误是把 rate.NewLimiter 写在 Gin 中间件函数体内部——每个请求进来都新建一个 limiter，相当于每人发一个无限额度的令牌桶。它不共享状态，也不计数，完全起不到限制作用。
- 正确做法：全局初始化一个或多个 limiter 实例，按 key 复用（比如用
sync.Map存path → *rate.Limiter） - burst 值别设成 1：至少为 QPS 的 2–3 倍，否则突发请求（如重试、前端批量请求）直接被拒
- 别用
Allow()判断后才执行业务：它非阻塞，高并发下可能瞬间打穿阈值；改用Wait(ctx)并配context.WithTimeout
rate.Every(100 * time.Millisecond) 和 rate.Limit(10) 到底差在哪
这两个参数语义不同，混用容易误配。例如 rate.Limit(10) 表示“每秒最多 10 次”，而 rate.Every(100 * time.Millisecond) 明确表达“每 100ms 放一个令牌”，更直观不易错。
-
rate.Every(200 * time.Millisecond)≡rate.Limit(5)，但前者可读性更强，推荐优先使用 - 如果想支持短时爆发（比如登录页被刷），burst 设为 15 比设为 1 更合理——它允许最多积压 15 个令牌，不是并发数
- 注意：burst 过大会削弱限流效果；过小会导致正常重试也被拦截，需结合监控调整
如何避免健康检查接口被限流拖垮 K8s 探针
把限流中间件无差别套在所有路由上，/healthz 或 /readyz 一旦返回 429，K8s 就会反复重启 Pod，形成雪崩闭环。
- 必须在中间件里显式放行特定路径：
if strings.HasPrefix(c.Request.URL.Path, "/health") { c.Next(); return } - 更稳妥的做法是按路由组启用限流：只对
api.Group("/v1")加中间件，静态资源和探针路径走独立路由树 - 别忘了限流响应头：
c.Header("X-RateLimit-Limit", "100")、"X-RateLimit-Remaining"，方便前端或网关协同降级
分布式场景下为什么不能只靠 rate.Limiter
rate.Limiter 是纯内存实现，每个 Pod 各自维护一套计数器。3 个副本 × 每秒 100 请求 = 实际承载 300 QPS，远超你配置的阈值。
- 跨实例限流必须依赖外部存储，Redis + Lua 是最常用方案，关键是要用原子脚本完成“清理窗口 + 计数 + 插入”三步
- 别用
INCR+EXPIRE两步操作：存在竞态，两个请求同时看到 0，都会写入并设过期，导致计数翻倍 - key 设计要带时间精度：比如
rate:ip:192.168.1.1:2026060210（小时级），比固定窗口更平滑
真正难的不是写限流逻辑，而是决定“谁该被限”和“限多少”——IP、User ID、API Path、Token 这些 key 的粒度选错，会让限流变成误伤工具。上线前务必用真实流量打标验证，而不是只看本地压测数字。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
