rate.Limiter仅适用于单机限流，多实例部署时必须分层设计——全局、服务级、接口级、用户级限流不可混用，否则会因阈值统一导致误限或压不住流量；用户级限流必须用Redis+Lua实现分布式原子计数。
rate.Limiter 单机有效，多实例部署时必须分层设计——全局、服务级、接口级、用户级限流不能混用同一套逻辑，否则要么压不住流量，要么误杀正常请求。
为什么不能只用一个 rate.Limiter 全局兜底
全局单例 rate.Limiter 看似省事，但实际会破坏业务语义：
- 支付接口需要严格限流（如 5 QPS/用户），登录接口却要容忍突发（如 100 QPS/IP）——统一阈值无法兼顾
- 运营后台接口调用量低但权限高，被和 API 流量共用桶后容易被误限
- 当某条路由因 bug 触发高频重试，单桶策略会让整个服务“陪绑”降级
- 横向扩到 8 个实例时，若每个实例都用
rate.Limiter(10, 10)，实际总放行能力是 80 QPS，远超预期
四层限流结构怎么组织才不冲突
推荐按「拦截前置度」从外到内分层，每层失败即终止，不透传到下一层：
- 接入层（Nginx / API 网关）：基于 IP 或 ASN 做粗粒度防护，例如单 IP 每秒不超过 200 请求，防扫描和基础爬虫
-
服务级（Go 进程内）：用
sync.Map+rate.Limiter按service_name分桶，控制该服务整体吞吐，避免拖垮机器资源 -
接口级（HTTP 路由）：按
r.URL.Path或r.Header.Get("X-Api-Name")动态生成 key，例如/v1/order/create单独配 30 QPS -
用户级（业务维度）：提取
user_id或app_key，走 Redis + Lua 实现分布式计数，保证“每个用户每分钟 ≤ 60 次”，不依赖单机状态
注意：四层不是必须全上，而是按风险等级叠加。比如内部 RPC 调用可跳过 IP 层，直奔服务级 + 接口级。
rate.Limiter 在多层中如何复用与隔离
关键在初始化方式和 key 构建逻辑，避免 goroutine 泄漏或误共享：
立即学习“go语言免费学习笔记（深入）”；
- 不要在 handler 内
new rate.Limiter—— 每次新建等于放弃限流 - 接口级限流建议用
map[string]*rate.Limiter+sync.RWMutex，读多写少，性能损耗可忽略 - 用户级限流绝不用
sync.Map[string]*rate.Limiter存长期状态 —— 无自动过期，内存持续增长，且跨实例失效 - 如果用 Redis 做用户限流，
INCRBY key 1+EXPIRE key 60必须封装进 Lua 脚本，否则存在竞态导致超限 - 所有
WaitN(ctx, 1)必须传入r.Context()，否则客户端断连时 goroutine 会卡死在等待令牌
配置热更新怎么避免重启服务
硬编码阈值等于放弃运维灵活性，生产环境必须支持运行时调整：
- 用
atomic.Value包裹*rate.Limiter实例，更新时Store()新实例，旧实例自然被 GC - Redis 限流的
rate和burst可存在 etcd 或 Consul 中，起一个 goroutine 定期Watch变更 - 别监听文件修改再 reload —— 文件 I/O + 解析 + 替换结构体易出错，且无法原子切换
- 每次更新后打日志：
limiter updated for /v1/pay: rate=5, burst=10，方便对账
最易被忽略的一点：用户级限流的 key 设计必须带租户或环境前缀，比如 prod:user:12345:api_limit，否则测试环境刷出来的数据会污染线上 Redis。
