正确做法是用LRU缓存或带过期的map管理IP对应的rate.Limiter实例，设置10分钟无访问即驱逐，并标准化IPv4/IPv6地址、校验可信X-Forwarded-For、返回429时不暴露策略细节、放行健康检查路径、避免压测时时间塌缩导致限流不准。
用 golang.org/x/time/rate 做 IP 限流，但别直接按 IP 做 Limiter
直接为每个 IP 新建一个 rate.Limiter 实例，短期测试看似可行，但线上跑几天就会内存暴涨甚至 OOM。因为 rate.Limiter 是有状态的（内部维护 last、tokens 等字段），长期存活的实例不会自动回收，而用户 IP 是动态、海量且不可控的。
正确做法是：用固定大小的 LRU 缓存（如 github.com/hashicorp/golang-lru）或带过期的 map（配合 sync.Map + 定时清理）来管理 IP 对应的 rate.Limiter 实例，并设置合理生存时间（例如 10 分钟无访问即驱逐）。
- 每 IP 限流阈值建议设为
rate.Every(1 * time.Second)配合burst=5，避免误杀爬虫或重试请求 - 缓存 key 必须标准化：IPv4 和 IPv6 要统一处理（如 IPv6 去掉前导零、压缩格式），否则同一客户端可能生成多个 key
- 不要用
time.Now()做缓存过期判断——高并发下频繁调用有性能损耗；改用「最后访问时间戳 + TTL」方式更轻量
从 *http.Request 中提取真实客户端 IP 要防伪造
直接读 r.RemoteAddr 只能得到直连 TCP 客户端地址（通常是反向代理或负载均衡器自己的 IP），不是真实用户 IP。必须解析 X-Forwarded-For 或 X-Real-IP，但这两个 header 都可被客户端随意伪造。
安全做法是：只信任你可控的上游代理所添加的 header，并配置可信跳数（trustedHop）。例如 Nginx 在最外层，且只加一次 X-Forwarded-For，那就取该 header 最右非私有地址（注意顺序是「客户端, 代理1, 代理2…」）。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 私有 IP 列表要完整：
127.0.0.1/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、::1/128、fc00::/7 - 若使用 Cloudflare，优先读
Cf-Connecting-Ip（它不可伪造），再 fallback 到校验后的X-Forwarded-For - 永远不把未经校验的 header 值直接用于限流或日志——可能引入注入或统计偏差
限流失败时返回 429 Too Many Requests，但别暴露具体策略
返回 429 是标准做法，但别在响应头里写 Retry-After: 1 或 X-RateLimit-Remaining: 0 这类信息。攻击者会据此调整请求节奏，绕过限制；正常用户也无需知道后端配的是 5qps 还是 10qps。
更稳妥的做法是：只返回 429 状态码 + 一个通用提示 body（如 {"error": "too many requests"}），其他 header 全部省略。如果业务允许，可随机延迟 100–500ms 再返回，增加自动化探测成本。
- 别在日志里打印被限流的完整 IP（尤其含公网 IPv4），避免泄露用户标识；可用哈希脱敏，如
sha256(ip)[:8] - 对内网接口或健康检查路径（如
/healthz）务必放行，否则监控系统自己把自己干掉 - 若用 Gin/Echo 等框架，确保中间件 panic 捕获逻辑在限流之后执行，否则限流异常可能被吞掉
压测时发现限流不准？检查时钟精度和令牌桶重置逻辑
用 ab 或 hey 压测时，常出现「明明设了 10qps，结果每秒放行 15+ 请求」。根本原因不是代码错，而是 rate.Limiter 的令牌发放基于 wall clock，而高并发下多次 Allow() 调用可能落在同一个纳秒级时间片内，导致 burst 被一次性耗尽。
这不是 bug，是设计使然。应对方法只有两个：一是调大 burst 值（比如设为 qps 的 2–3 倍），接受短时毛刺；二是改用滑动窗口算法（如 golang.org/x/exp/maps + 时间分片），但会显著增加内存与 GC 压力，一般没必要。
- 避免在循环里反复调用
limiter.Allow()而不 sleep——这会人为制造时间塌缩，让测试失真 - 生产环境观察限流效果，优先看 Prometheus 的
http_requests_total{code="429"}曲线，而不是单次请求响应头 - 如果业务对精度要求极高（如支付风控），就别用
rate包，直接上 Redis + Lua 做分布式滑动窗口
实际部署时，最易被忽略的是 IP 提取链路和缓存淘汰策略的组合效应：IP 解析错了，限流就全歪了；缓存不淘汰，内存就涨没了。这两处没调稳，其他都白搭。
