登录限流必须按IP+账号组合维度隔离，采用滑动窗口或令牌桶算法，统一统计所有请求（含成功、失败、被限流），触发后锁定账号/IP、降级验证并告警，且限流逻辑须在未登录时手动触发、用Redis存储。
直接用 rate.Limiter 全局限流会误杀正常用户
全局限流等于把所有请求塞进同一个桶，NAT 环境下几十个用户共用一个出口 IP，一人刷爆，全员 429；登录接口和后台管理页也互相干扰。必须按维度隔离实例：
- 优先取认证后的
c.GetString("user_id")，但认证中间件必须注册在限流中间件之前，否则取不到值 - 未认证时用
c.ClientIP()，注意 IPv6 地址含冒号，建议先strings.ReplaceAll(ip, ":", "-")标准化 - 用
sync.Map缓存每个 key 对应的*rate.Limiter，key 形如"ip:" + ip或"uid:" + uid - 每个新 key 需配过期清理：
time.AfterFunc(5*time.Minute, func() { limiterMap.Delete(key) })，否则内存持续增长
Allow()、ReserveN()、WaitN() 到底怎么选
三个方法都消耗令牌，但行为完全不同，错用会导致前端无法重试、goroutine 挂起或剩余数不准：
-
Allow()：非阻塞，返回bool。适合登录防爆破这类“快速失败”场景，没令牌立刻c.AbortWithStatusJSON(http.StatusTooManyRequests, ...) -
ReserveN()：返回*rate.Reservation，可调.OK()和.Delay()。适合需提示“请等待 X 毫秒”的表单提交 -
WaitN()：阻塞直到拿到令牌或 context 超时。**绝不能裸用WaitN(context.Background(), n)**，必须传带 timeout 的 context，例如：ctx, cancel := context.WithTimeout(c.Request.Context(), 100*time.Millisecond) - 批量操作（如一次上传 3 个文件）要用
WaitN(ctx, 3)，注意：这不是允许 3 并发，而是“这 3 个请求必须同时放行或同时拒绝”
分布式部署下必须用 Redis + Lua 原子计数
单机 rate.Limiter 在多实例后完全失效——每个进程只统计自己收到的请求。真实流量打到不同 Pod，限流阈值直接翻倍。Redis 是唯一可靠方案：
- Key 命名要含双维度：
"rate:ip:" + realIP + ":api/v1/submit"或"rate:uid:" + uid + ":api/v1/submit" - 必须用 Lua 脚本一次性完成 INCR、判断是否超限、EXPIRE，避免分步执行导致 key 永久残留
- 别信 pipeline 包装的“原子性”——它只是批量发命令，不保证执行顺序和一致性；
EVAL才是真原子 - Lua 脚本里不能依赖 Redis 的
TIME，必须由客户端传入当前时间戳（ARGV[3]），否则时钟漂移会导致桶填充异常
IP 白名单校验不能只靠字符串匹配
直接 strings.Contains(referer, "example.com") 容易被绕过或误杀。Referer 必须先解析再比对：
- 空
Referer要明确策略：记录日志并放行，或直接c.AbortWithStatusJSON(http.StatusForbidden, ...) - 用
url.Parse(c.Request.Referer())解析，检查err != nil和u.Host == "" - 白名单应为完整 host 字符串（如
"app.example.com"），禁止用strings.HasSuffix(u.Host, ".example.com")，否则evil.example.com可绕过 - Gin 中校验失败后必须显式
return，否则后续 handler 仍会执行
sync.Map 会吃光内存，没 timeout 的 WaitN 会让 goroutine 永久挂起。 
