用 golang.org/x/time/rate 实现 IP 限流需为每个 IP 绑定独立 rate.Limiter（如存于 sync.Map），合理设置 Every 和 burst，定期清理闲置 IP；HTTP 中间件须按可信代理网段解析真实客户端 IP，避免伪造；高并发时可哈希分片 sync.Map 或改用 Redis。
用 golang.org/x/time/rate 做 IP 级限流最直接
标准库没有内置 IP 限流，但 rate.Limiter 是唯一靠谱的底层组件——它轻量、无锁、精度可控，且不依赖外部存储。别碰 time.Sleep 手搓计数器，也别一上来就上 Redis，90% 的场景用它就够了。
关键不是“能不能做”，而是“怎么把 IP 和 Limiter 绑定住”。常见错误是全局只用一个 Limiter，结果所有 IP 共享额度；或者为每个新 IP 频繁新建 Limiter 却不回收，导致内存缓慢上涨。
- 每个 IP 对应一个独立的
rate.Limiter实例（比如存在sync.Map中） - 用
rate.Every(1 * time.Second)表示“每秒最多 N 次”，比rate.Limit(N)更直观 - 设置合理的
burst（比如 5），避免网络抖动导致正常请求被误拒 - 定期清理长时间未访问的 IP 条目（例如 30 分钟无请求就
delete），否则sync.Map会持续膨胀
HTTP 中间件里怎么安全提取真实客户端 IP
直接读 r.RemoteAddr 只能得到代理或负载均衡器的地址，不是真实用户 IP。必须按顺序检查 X-Forwarded-For、X-Real-IP 等 header，但不能全信——这些字段可被伪造。
真正能信任的只有你自己的反向代理（如 Nginx）加的 header，而且必须配置 set_real_ip_from + real_ip_header。Golang 层要做的是：只从可信 hop 列表里取最后一个非内网地址。
立即学习“go语言免费学习笔记（深入）”；
- 硬编码可信代理网段（如
"10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"），其他来源的X-Forwarded-For一律忽略 - 用
net.ParseIP+net.Contains判断是否为内网地址，别用字符串匹配 - 如果所有 header 都不可信，fallback 到
r.RemoteAddr的 IP 部分（用strings.Split(r.RemoteAddr, ":")[0]） - 注意 IPv6 地址格式，
r.RemoteAddr可能带方括号，需先net.ParseIP再格式化输出
并发高时 sync.Map 性能不够怎么办
sync.Map 在读多写少时表现好，但每秒几千次写入（比如大量新 IP 首次访问）会导致 LoadOrStore 明显延迟。这不是 bug，是设计取舍：它不保证遍历一致性，也不支持原子删除。
真到这一步，与其魔改，不如换更合适的结构。别自己实现分片 map，Go 生态已有验证过的方案。
- 用
github.com/cespare/xxhash/v2对 IP 做哈希，再对固定数量（如 64）取模，路由到不同sync.Map实例，实现简易分片 - 如果已有 Redis，用
INCR+EXPIRE组合（注意用 pipeline 减少 RTT），比本地 map 更易横向扩展 - 避免在限流路径里做 DNS 解析或 HTTP 调用——哪怕只是查个 geoip，也会让平均延迟从微秒级跳到毫秒级
- 压测时重点看
runtime.ReadMemStats中的Mallocs和 GC Pause，高频新建Limiter是隐性性能杀手
测试时为什么本地 localhost 总被限流
因为 127.0.0.1 和 ::1 都算有效 IP，同样走限流逻辑。开发阶段反复刷页面，很容易触发 burst 耗尽，接着每秒只能进 1 个请求，显得“功能坏了”。
这不是代码缺陷，是限流机制生效的正常表现。绕过方式要明确区分环境，而不是删逻辑。
- 加个开关变量（如
disableRateLimit bool），仅在os.Getenv("ENV") == "dev"时设为 true - 测试用例里手动构造
http.Request时，把r.RemoteAddr设成随机 IP（如"192.168.1.100:12345"），避免全部挤在 127.0.0.1 - 别在中间件里写
if ip == "127.0.0.1" { return }——上线后可能漏掉真实攻击源 - Docker 环境下注意宿主机和容器网络模式，
localhost在容器内可能指向 bridge 网关而非你的服务进程
IP 限流真正的复杂点不在算法，而在 IP 的真实性判断和生命周期管理。很多人卡在“为什么限了不该限的”，其实问题早出现在第一层 header 解析里。
