Gin限流中间件必须用c.Next()链式调用且拒绝时需c.JSON()+c.Abort()+return；令牌桶适合突发流量但单机无法共享状态；rate与capacity需合理配置，分布式限流需Redis或Sentinel支持。
直接说结论：Gin 限流中间件必须用 c.Next() 链式调用，不能直接返回响应；令牌桶比计数器更适合突发流量，但单机实现无法跨实例共享状态。
为什么 c.Abort() 后必须 return
常见错误是限流拒绝后只调用 c.Abort() 却没加 return，导致后续逻辑仍执行。Gin 的中间件流程依赖显式控制流：一旦调用 c.Abort()，当前中间件链终止，但函数本身不会自动退出。若不 return，c.Next() 或业务 handler 仍可能被调用，造成重复响应或 panic。
-
c.Abort()只是标记“跳过后续中间件”，不中断当前函数执行 - 限流拒绝时必须写成：
c.JSON(429, gin.H{...}); c.Abort(); return - 漏掉
return在日志里可能看到“multiple response.WriteHeader calls”错误
NewLimiter 的 rate 和 capacity 怎么设才合理
这两个参数不是随便填的数字，它们共同决定系统实际承受能力。比如设置 rate=5、capacity=10，意味着：每秒最多补充 5 个令牌，桶最多存 10 个——允许短时间突发 10 个请求，但长期平均不能超过每秒 5 个。
-
capacity应 ≥rate，否则桶永远装不满，突发能力为 0 - 秒级限流（如 API 调用配额）建议
rate设为整数，单位是“每秒令牌数” - 分钟级限流（如用户登录尝试）需换算：
rate = 60对应“每分钟 60 次”，但注意令牌桶是按秒填充，所以实际是“平均每秒 1 次”，峰值仍由capacity控制 - 数据库连接池类资源保护，
capacity可设为连接池最大数，rate设为预期平均 QPS
单机限流中间件在多实例部署下会失效
所有基于内存变量（如 tokens int、timestamps map[string][]int64）的实现，天然只对当前进程有效。当服务跑多个副本时，每个实例维护自己的桶，总请求量很容易突破设定阈值。
立即学习“go语言免费学习笔记（深入）”；
- 测试时本地单例跑得通，上线后压测发现限流形同虚设，大概率是这个原因
- 简单方案：用 Redis + Lua 做原子操作，例如
redis-cell模块或自写 EVAL 脚本 - 进阶方案：接入 Sentinel 或 Nacos 的分布式限流规则中心，但引入额外运维成本
- 如果只是内部服务且流量可控，可先用 IP + 时间窗口计数器（如每分钟 per-IP 限制），它比令牌桶更容易做分布式，但不支持突发
别把 time.Now().Unix() 当作高精度时间源
在高频请求场景下，time.Now().Unix() 秒级精度不够，会导致同一秒内多个请求被当成“同时到达”，桶刷新逻辑出错。更稳妥的做法是用 time.Now().UnixNano() 或直接依赖 time.Since() 计算间隔。
- 原生
time.Now().Unix()在 Linux 上通常只有 10ms 级精度，Go 1.19+ 才提升到纳秒级，但不同 OS 差异大 - 令牌桶中判断
now > l.next时，若l.next是秒级时间戳，而now是纳秒级，比较结果可能不稳定 - 推荐统一用
time.Now().UnixMilli()（Go 1.17+）或time.Now().UnixNano()，并确保next字段类型匹配
真正难的不是写出来，而是想清楚限流粒度——按 IP？按用户 ID？按 API 路径？还是组合维度。这些决策直接影响存储选型和性能瓶颈，代码反而只是最后一步。
