rate.Limiter是基于令牌桶算法的轻量限流方案，需按IP或用户维度隔离实例并用sync.Map缓存，正确提取真实IP，分层实现全局限流与单用户限流，拒绝而非阻塞请求。
用 golang.org/x/time/rate 实现简单可靠的接口限流
标准库外最常用、最轻量的限流方案就是 rate.Limiter，它基于令牌桶算法，精度高、无锁、支持突发流量控制。直接在 HTTP handler 中使用即可，无需引入额外依赖。
常见错误是把 rate.NewLimiter 实例写死在 handler 函数里，导致所有请求共享同一个限流器——这会把整个接口当成一个整体来压，而不是按 IP 或用户维度隔离。
- 每个需要独立限流的维度（如
userID、ip）应维护自己的*rate.Limiter实例 - 用
sync.Map缓存限流器，避免高频创建/销毁开销；注意设置合理的过期清理逻辑（比如 1 小时未访问则删除） -
limiter.Allow()返回false时立即返回http.StatusTooManyRequests，不要继续执行业务逻辑 - 令牌桶容量（
burst）建议设为期望 QPS 的 2–3 倍，防止偶发抖动被误拒
按 IP 限流时如何正确提取客户端真实地址
直接读 r.RemoteAddr 只能得到反向代理（如 Nginx）或负载均衡器的 IP，实际限流会失效。必须从请求头中解析真实来源，但不能盲目信任 X-Forwarded-For。
- 只信任你可控的上游代理所添加的
X-Forwarded-For字段，且需配置 Nginx 使用proxy_set_header X-Forwarded-For $remote_addr;（非$proxy_add_x_forwarded_for） - Go 中推荐用
realip.FromHeaders(r.Header, realip.Config{Trusted: []string{"10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"}})（来自github.com/zenazn/goji/web/util/realip或类似工具），避免手写解析出错 - 若服务直面公网（无代理），才可 fallback 到
r.RemoteAddr并手动截掉端口部分
全局 QPS 限制与单用户 QPS 限制能否共存
能，但必须分层实现：全局限流走中间件级共享限流器，单用户限流走键值隔离限流器，二者不互相替代。
立即学习“go语言免费学习笔记（深入）”；
- 全局限流适合防雪崩，用一个固定的
*rate.Limiter放在最外层 middleware，Allow()失败直接中断请求 - 单用户限流用于防刷，key 为
"user:" + userID或"ip:" + ip，限流器生命周期由sync.Map管理 - 不要在一个请求里先后调两次
Allow()—— 全局限流失败就该终止，不应再进用户级判断，否则增加延迟且逻辑混乱 - 如果用 Redis 实现分布式限流，
INCR + EXPIRE组合有竞态，优先用EVAL脚本或 Redis 6.2+ 的INCRBYEX
为什么不用 time.Sleep 或 context.WithTimeout 做限流
它们不是限流，是阻塞或超时控制。限流的目标是「拒绝」而非「等待」，否则会堆积 goroutine、耗尽连接池、放大延迟。
-
time.Sleep会让 handler 阻塞，HTTP server 的 worker goroutine 被占用，QPS 上不去还容易触发连接超时 -
context.WithTimeout只控制单次操作生命周期，无法统计单位时间请求数，也不提供令牌发放/消费语义 - 真正要“削峰填谷”，得靠异步队列（如 Kafka）+ 后台 Worker，不是 HTTP 接口层该干的事
限流的边界常被模糊：它只负责保护后端不被冲垮，不负责保证用户体验。该返回 429 的时候，别想着“等等再试”，而是明确告诉调用方“你现在太频繁了”。
