不能直接用rate.newlimiter做三维度限流，因其无key概念，所有请求共享同一令牌桶；必须为每个ip+用户id+接口路径组合创建独立limiter实例，并用sync.map安全存取、定时清理过期项。
为什么不能直接用 rate.NewLimiter 做三维度限流
因为 rate.Limiter 本身不带 key 概念，它只管“每秒多少次”，所有调用都往同一个桶里扔 token。你传一个 IP、一个用户 ID、一个接口路径进去，它根本分不清——结果是管理员和游客共用配额，健康检查接口和登录接口被一起掐断。这不是限流，是随机误伤。
真正要联合控制 IP + 用户 ID + 接口路径，必须为每个唯一组合生成独立的 rate.Limiter 实例，并安全地存起来、查得到、删得掉。
- 常见错误：多个 goroutine 同时发现 key 不存在，同时调
rate.NewLimiter，再同时写进 map → 触发concurrent map writes - 另一个坑：不设清理机制，攻击者构造
1.1.1.1:user_999:/api/v1/xxx、1.1.1.1:user_999:/api/v1/yyy……内存持续上涨直到 OOM - 别用普通
map[string]*rate.Limiter，必须用sync.Map或加sync.RWMutex
怎么拼出安全可靠的限流 key
key 是三维度联合的唯一标识，拼错就等于限流失效或误杀。最稳妥的是用分隔符明确、可逆、无歧义的格式：
- 推荐：
fmt.Sprintf("%s|%s|%s", cleanIP, userID, cleanPath)，竖线|比冒号:更少冲突（比如 IPv6 地址自带冒号） -
cleanIP必须标准化：IPv4 不变；IPv6 去前导零、压缩格式统一（如2001:db8::1），避免同一客户端生成多个 key -
userID别直接用原始参数值——未登录用户可能传空串或"anonymous"，建议统一为"guest"；敏感字段如手机号需脱敏后使用 -
cleanPath要去除查询参数和 trailing slash，比如/api/order?status=paid→/api/order，否则/api/order和/api/order/会被当成两个 key
如何避免新建 limiter 时并发冲突
懒加载是必须的，但“查无则建”这步不能裸奔。两个 goroutine 同时查不到 key，就会各自新建、各自写入，丢一个实例，还可能造成后续限流失效。
- 正确做法：用
sync.Map.LoadOrStore，它保证“查+存”原子性。传一个工厂函数进去，仅当 key 不存在时才执行，且只执行一次 - 示例：
limiter, _ := limiterMap.LoadOrStore(key, rate.NewLimiter(rate.Every(1*time.Second), 5)) - 注意：不要在工厂函数里做重 IO 或耗时操作（比如查 DB），
LoadOrStore是阻塞的，会拖慢第一个请求 - 如果初始化需要动态读配置（比如不同用户 ID 有不同配额），建议先查缓存或本地 map，再传进
NewLimiter
不清理 key 的后果比你想的更严重
线上跑一周，sync.Map 里可能积压数万甚至数十万个长期不用的 limiter 实例。每个 rate.Limiter 虽小，但内部有 last、tokens、limit 等字段，加上 GC 压力，内存增长不可忽视。
- 别依赖“等 GC 回收”，
rate.Limiter不会自己过期 - 推荐方案：启动一个后台 goroutine，每分钟扫描一次，对最后访问时间戳超过 10 分钟的 key 调用
Delete - 更轻量的做法：不主动扫描，改用“访问时惰性驱逐”——每次
Load到 limiter 后，检查其最后活跃时间，超时就Delete并返回 nil，让下一次请求重建 - 千万别用
time.Now()频繁判断过期，高并发下损耗明显；存一个atomic.Int64记录最后访问 Unix 时间戳即可
三维度限流真正难的不是“怎么写逻辑”，而是 key 的生成是否鲁棒、并发创建是否安全、闲置资源是否及时回收——这三个点漏掉任何一个，上线后都会变成隐性故障源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
