直接用 golang.org/x/time/rate 就够了，别自研令牌桶；它底层是纳秒级精度、线程安全、无锁的原子计数器，已优化高并发场景，自研易出时钟漂移、goroutine泄漏等问题。
限流策略选 golang.org/x/time/rate 还是自研令牌桶？
直接用 rate.Limiter 就够了，别自己实现令牌桶逻辑。它底层是带时间戳的原子计数器，线程安全、无锁、精度到纳秒，且已针对高并发场景做过优化。自研容易在重置窗口、时钟漂移、goroutine 泄漏上出问题。
注意：它默认按「固定速率」限流（比如每秒 10 次），不支持滑动窗口或按 IP 动态配额——这得你自己加一层映射和过期管理。
-
rate.NewLimiter的burst参数不是并发数，而是允许突发请求数；rate.Every是平均间隔，不是最小间隔 - 不要把同一个
rate.Limiter实例复用于不同 IP：它不带标识，共享会串流 - 如果 QPS 配置需运行时变更，别直接替换 limiter 实例，要用
SetLimitAndBurst方法（v0.12+ 支持）
如何按客户端 IP 做键值隔离？
用 sync.Map 存 map[string]*rate.Limiter 最省事，但要注意内存无限增长。真实场景必须加 TTL 清理，否则爬虫扫一遍就 OOM。
推荐组合：sync.Map + 后台 goroutine 定期扫描 + time.Now().Unix() 作为 last_used 时间戳存进 value 结构体里。别用 time.Timer 为每个 IP 单独设过期，成本太高。
- IP 提取别只看
r.RemoteAddr，要检查X-Forwarded-For或X-Real-IP（前提是反向代理可信） - IPv6 地址要规范化（如去掉前导零、统一小写），否则同一 IP 可能被当两个 key
- 如果用 Redis 做分布式限流，
rate.Limiter不能直接序列化，得改用redis-cell或 Lua 脚本模拟令牌桶
怎么避免冷启动时突发流量打穿？
新 IP 第一次访问时，rate.Limiter 默认允许 burst 次请求 —— 这对恶意扫描是漏洞。需要手动调用 limiter.ReserveN(time.Now(), 1) 并检查 .OK()，再决定是否放行。
更稳妥的做法是初始化时预热：对新 IP 创建 limiter 后，立刻 ReserveN(now, burst) 再丢弃，让桶初始状态为“已消耗满”，等时间自然恢复。
- 别在
http.Handler里每次请求都调limiter.Allow()：它不阻塞，但返回 false 时你得主动返回 429，否则静默失败 - 记录被限流的 IP 时，用
log.Printf会拖慢响应，建议异步写入 ring buffer 或发到 metrics 上报通道 - 如果后端是 gRPC，HTTP 中间件里的限流无法覆盖，得在 server 端单独做，且要解析
peer.Addr获取真实 IP
为什么本地测试总显示限流不准？
因为 rate.Limiter 的精度依赖系统时钟，而 Docker 容器或 WSL2 的时钟可能漂移，尤其在 CPU 负载低时。本地压测用 ab 或 hey 发请求太快，limiter 还没来得及更新时间戳就被连续调用，导致误判。
验证方法：用 time.Sleep 控制单 goroutine 请求节奏，或改用 limiter.WaitN(ctx, 1) 让其真正阻塞等待，比 Allow() 更易观察行为。
- 测试时关掉所有中间件（如 CORS、JWT 验证），排除干扰耗时
- 打印
limiter.Limit()和limiter.Burst()确认配置已生效，而不是靠猜 - Go 1.22+ 引入了
rate.Sometimes辅助类型，适合做采样限流，但不适用于精确的 IP 级硬限流
动态 IP 限流真正的难点不在算法，而在清理策略和边界判断——比如 NAT 后多用户共用一个公网 IP 怎么办，或者 CDN 回源时如何识别原始客户端。这些没法靠库解决，得结合业务日志和用户身份体系做二次校准。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
