最有效、最轻量的防御高频自动化攻击方式是用golang.org/x/time/rate配合sync.Map按IP或用户ID维护独立*rate.Limiter实例；全局单实例会导致所有请求共享桶而误杀正常用户，必须分桶隔离并定期清理过期项。
直接用 golang.org/x/time/rate 配合 sync.Map 按 IP 或用户 ID 维护独立 *rate.Limiter 实例，是最有效、最轻量的防御高频自动化攻击的方式。别信“防抖中间件”这种说法——服务端没有防抖，只有限流。
为什么不能只用全局 rate.Limiter
全局单实例会把所有请求塞进同一个桶，NAT 用户、爬虫 IP、正常用户互相挤占配额，导致误杀或漏放。比如你设了每秒 5 次，结果一个恶意 IP 把 5 个令牌全占了，其他几十个真实用户全被 429 拦住。
-
rate.Limiter本身并发安全，但「共享桶」不等于「合理限流」 - IP 可伪造，
c.ClientIP()必须配合router.SetTrustedProxies()才可信 - 未登录场景下，只能依赖 IP；已登录必须优先用
c.GetString("user_id")，且认证中间件必须注册在限流之前
如何用 sync.Map 动态管理每个维度的限流器
核心是避免为每个新 IP 都新建 goroutine 清理，也不用引入 LRU 库——直接用带过期时间的 value 就行。
- key 设计建议：
c.ClientIP() + ":" + c.Request.URL.Path（路径级隔离），IPv6 要先net.ParseIP再.String()标准化 - value 存结构体：
{limiter *rate.Limiter, lastUsed time.Time}，每次访问更新lastUsed - 清理逻辑：起一个后台 goroutine，每 30 秒扫一次
sync.Map，删掉time.Since(v.lastUsed) > 5 * time.Minute的项 - 别用
map + sync.Mutex—— 高并发下锁竞争明显，sync.Map在读多写少场景下性能优势显著
Allow()、ReserveN()、WaitN() 怎么选
选错会导致超时挂起、前端无法重试、或突发流量直接打穿防线。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
Allow()：适合登录、短信发送等「强拒绝」场景，没令牌立刻返回http.StatusTooManyRequests，响应头加X-RateLimit-Remaining和X-RateLimit-Reset -
ReserveN(now, n)：需要预判等待时间时用，比如前端想提示「请 280ms 后重试」，查r.Delay()即可 -
WaitN(ctx, n)：**绝不能裸用context.Background()**，必须传带 timeout 的 ctx（如ctx, _ := context.WithTimeout(c.Request.Context(), 100*time.Millisecond)），否则恶意客户端长连接可能让 handler 永久阻塞
生产环境必须绕开的坑
单机限流在负载均衡后就失效，但不是所有场景都得上 Redis。先看清楚你的瓶颈在哪。
- 如果只是防脚本爆破登录接口，单机
rate.Limiter+ IP 维度完全够用，加 Redis 反而引入延迟和故障点 - 真要分布式，别用 ZSet 做滑动窗口——高 QPS 下 Redis 延迟抖动大，INCR + EXPIRE 固定窗口更稳
-
rate.Every(time.Second/10)是每 100ms 放 1 个令牌（即 10 QPS），别写成time.Second/15还以为是 15 QPS - 错误响应必须用
http.StatusTooManyRequests（429），前端才能统一拦截重试逻辑；用 400 或 500 会让前端误判为业务错误
真正难的不是写限流代码，而是决定「对谁限、限多少、什么时候放宽」——比如 /login 接口要严，/status 健康检查接口要放行，这些策略没法靠算法自动推导，得结合日志、监控和攻击特征人工调优。
