直接用全局rate.limiter会误杀正常用户，因为所有请求共用同一令牌桶，导致nat下多用户共享ip时一人刷爆全员受限，且不同接口（如登录与管理页）相互干扰；必须按ip或用户id维度隔离实例、设置过期清理，并在分布式场景下改用redis+lua原子计数。
服务端没有“防抖”，只有限流；IP限流若不加维度隔离和过期清理，等于没设。
为什么直接用 rate.Limiter 全局限流会误杀正常用户
全局限流指所有请求共用一个 *rate.Limiter 实例，比如在中间件里写死 r := rate.NewLimiter(rate.Limit(10), 5)。这会导致：NAT 环境下多个用户共享同一出口 IP，一人刷爆就全员 429；登录接口和查询接口共用桶，注册流量高峰直接卡死后台管理页。
必须按维度拆分实例：
- 每个
c.ClientIP()对应独立*rate.Limiter，用sync.Map缓存，key 是标准化后的 IP 字符串（IPv6 要处理冒号） - 若已认证，优先用
c.GetString("user_id")，但认证中间件必须注册在限流之前，否则取不到值 - 务必加过期逻辑：比如 5 分钟无访问就
delete对应 entry，否则内存持续增长 - 信任代理时调
router.SetTrustedProxies([]string{"10.0.0.0/8"})，再从X-Forwarded-For提取真实 IP
Allow()、ReserveN()、Wait() 到底该选哪个
三个方法都消耗令牌，但行为完全不同，错用会导致前端无法重试、请求永久挂起或剩余数误判：
-
Allow()：非阻塞，返回bool。适合登录防爆破这类“快速失败”场景，没令牌立刻c.AbortWithStatusJSON(http.StatusTooManyRequests, ...) -
ReserveN()：返回*rate.Reservation，可查.OK()和.Delay()。适合需要提示用户“请等待 X 毫秒”的场景，比如表单提交前前端倒计时 -
Wait()：阻塞直到拿到令牌或 context 超时。**绝不能裸用Wait(context.Background())**，必须传带 timeout 的 context，例如ctx, cancel := context.WithTimeout(c.Request.Context(), 100*time.Millisecond) - 批量操作（如一次上传 3 个文件）要用
AllowN()或WaitN()，但注意：拿 3 个令牌 ≠ 允许 3 并发，而是“这 3 个请求必须同时放行或同时拒绝”
分布式部署下 Redis + Lua 是唯一可靠方案
单机 rate.Limiter 在多实例后完全失效——每个进程只统计自己收到的请求，总量不可控。此时必须用 Redis 做原子计数：
- Key 命名要含双维度：
rate:ip:<code>c.ClientIP():api/v1/submit或rate:uid:<code>uid:api/v1/submit - 必须用 Lua 脚本一次性完成
INCR、判断是否超限、EXPIRE，避免INCR和EXPIRE分步执行导致 key 永久残留 - 首次请求前先
EXISTS，防止 key 不存在时INCR返回 0，误判为“未超限” - 别用
ZSet做滑动窗口——高 QPS 下 Redis 延迟飙升，固定窗口（INCR + EXPIRE）更稳
最容易被忽略的三个绕过点
攻击者不需要高技术，只要抓住这三个配置疏漏就能绕过限流：
- Token 未绑定 IP：用户复用有效 Token 换不同 IP 请求，限流 key 只含 UID 就失效
- IP 提取错误：没设
SetTrustedProxies，直接读c.Request.RemoteAddr，拿到的是负载均衡器 IP，所有请求都算作同一个 - 计数器未绑定上下文：中间件里用全局变量或闭包变量存 limiter，goroutine 复用导致不同请求共享状态
真正生效的限流，从来不是加个中间件就完事，而是维度设计、原子操作、上下文隔离三者缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
