直接用golang.org/x/time/rate做per-IP限流可行，但必须为每个IP绑定独立rate.Limiter实例并配TTL/LRU清理；否则将导致内存泄漏、所有IP共享一桶（限流失效）或并发panic。
直接用 golang.org/x/time/rate 做 per-IP 限流是可行的，但必须为每个 IP 绑定独立 rate.Limiter 实例，并配好清理逻辑；否则不是 panic 就是内存泄漏，或者所有 IP 共享一个桶——等于没限。
为什么不能只用一个全局 rate.Limiter
常见错误是把 rate.NewLimiter(10, 5) 放在中间件外层，所有请求共用它。结果是：100 个 IP 一起抢这 10 个令牌/秒，某个正常用户可能刚发两个请求就被卡住；反过来，恶意 IP 也能搭便车混在流量里漏过限制。
-
rate.Limiter本身无状态识别能力，它不关心“谁在用”，只管“有没有令牌” - 必须靠外部结构（如
sync.Map）按 IP 做 key 索引，才能实现真正的 per-IP 控制 - 若用
map[string]*rate.Limiter而非sync.Map，高并发下会直接 panic：map writes not safe from multiple goroutines
如何用 sync.Map + rate.Limiter 安全绑定 IP
核心是封装一个线程安全的限流器管理器，支持获取、新建、定期回收。别手动遍历清理，用 time.AfterFunc 或后台 goroutine 配合时间戳标记更稳妥。
- 用
sync.Map存ip → *rate.Limiter，避免锁整个 map - 每个
rate.Limiter初始化时用rate.Every(1 * time.Second)更直观，比rate.Limit(N)少一重换算 - burst 建议设为 3–5，太小易误杀（如 HTTP/2 多路复用、重试请求），太大则失去防护意义
- 对每个新 IP，启动一个
time.AfterFunc(30 * time.Minute, func(){ delete(...) })延迟清理，避免长期闲置条目堆积
HTTP 中间件里怎么取真实客户端 IP
直接读 r.RemoteAddr 几乎总是错的——你拿到的是负载均衡器或反向代理的 IP，不是用户真实出口 IP。不修正这点，限流就形同虚设。
立即学习“go语言免费学习笔记（深入）”；
- 优先检查
r.Header.Get("X-Real-IP")，这是 Nginx 默认透传的真实 IP - 其次 fallback 到
r.Header.Get("X-Forwarded-For")的第一个非私有地址（需自己解析并过滤10.0.0.0/8、192.168.0.0/16等） - 务必校验可信代理网段，否则攻击者伪造
X-Forwarded-For: 1.2.3.4, 127.0.0.1就能绕过所有限制 - Go 标准库没有内置 IP 段判断，用
net.ParseIP+*net.IPNet.Contains手动做
要不要上 Redis？看场景再决定
单机部署且 QPS sync.Map + rate.Limiter）完全够用；一旦跨多实例或需持久化策略，Redis 就不是“可选”，而是刚需。
- 用
github.com/ulule/limiter/v3可一键切换 memory / redis 后端，API 一致，迁移成本低 - Redis 方案天然解决分布式计数一致性，但要注意
INCR + EXPIRE非原子——得用 Lua 脚本或SET key value EX 60 NX组合 - 别用
DECR做倒计时，容易负数溢出；正确做法是INCR后立刻EXPIRE，查值时只比大小 - 如果只是防爬虫试探，claw-shield 这类配置驱动的中间件反而更省心，不用写代码就能开箱限流+UA 过滤
真正难的从来不是“怎么写个限流器”，而是怎么让 IP 解析不被伪造、怎么让内存不随时间增长、怎么让 burst 值既抗抖动又不放水——这些细节不抠清楚，上线后第一波爬虫来了，你就只能翻日志找为什么限流没生效。
