直接用 golang.org/x/time/rate 容易限不住流量，因其默认基于请求到达时间做令牌桶判断，单实例无法感知全局流量，导致多实例下总流量超限；真正可用的限流需跨实例共享状态、支持突发控制、区分调用方或接口粒度。
为什么直接用 golang.org/x/time/rate 容易限不住流量
因为 rate.Limiter 默认基于「请求到达时间」做令牌桶判断，但微服务中常有并发请求、网络延迟、重试等场景，单实例的 Limiter 无法感知全局流量。比如两个服务实例各自限流 100 QPS，实际总入口可能突增到 200 QPS，后端仍被打垮。
真正可用的限流必须满足：可跨进程/实例共享状态、支持突发流量平滑控制、能区分调用方或接口粒度。
- 单机限流只适合压测或开发环境验证，上线前务必替换为分布式方案
-
rate.Every(10 * time.Millisecond)这种写法隐含每秒 100 次，但实际吞吐受处理耗时影响，不是硬 QPS 限制 - 别把
Allow()放在 handler 最外层——它不阻塞，返回 false 后需主动 return，否则逻辑仍会执行
用 Redis + Lua 实现原子化分布式限流
核心是用 Redis 的 INCR + EXPIRE 组合存在竞态，必须用 Lua 脚本保证「计数+过期设置」原子性。Go 侧只需调用 Eval，无需自己加锁或重试。
典型脚本（key 是限流标识，如 "limit:api:/user/profile:192.168.1.100"）：
立即学习“go语言免费学习笔记（深入）”；
local current = redis.call("INCR", KEYS[1])
if current == 1 then
redis.call("EXPIRE", KEYS[1], tonumber(ARGV[1]))
end
if current > tonumber(ARGV[2]) then
return 0
end
return 1-
KEYS[1]是限流 key，建议包含服务名、接口路径、客户端 IP 或用户 ID -
ARGV[1]是窗口秒数（如 60），ARGV[2]是该窗口内最大请求数（如 1000） - Golang 调用时用
redisClient.Eval(ctx, script, []string{key}, windowSec, maxReq).Int() - 注意 Redis 连接池要足够大，避免限流逻辑本身成为瓶颈
如何给不同 API 设置差异化限流规则
硬编码每个接口的 maxReq 和 windowSec 不可持续。推荐用配置中心（如 etcd 或 Consul）动态加载规则，并监听变更。
结构示例（YAML）：
rules: - path: "/api/v1/order/create" method: "POST" limit: 50 window: 60 by: "client_ip" - path: "/api/v1/user/info" method: "GET" limit: 200 window: 60 by: "user_id"
- 解析后构造成 map[string]*Rule，key 可为
method:path（如"GET:/api/v1/user/info"） - 中间件中先匹配规则，再拼出 Redis key：
"limit:" + rule.by + ":" + value（value 来自r.Header.Get("X-User-ID")或r.RemoteAddr） - 没匹配到规则时，走默认限流（如 1000 QPS），避免配置遗漏导致全放开
限流日志与拒绝响应怎么写才不拖慢服务
记录每次被限流的请求详情（IP、path、UA）看似合理，但高频打日志会显著增加延迟和磁盘 IO。更稳妥的做法是采样记录 + 异步上报。
- 拒绝响应统一返回
http.StatusTooManyRequests，body 精简为 JSON：{"error":"rate_limited","retry_after":60} - 用
log.Printf前加个概率采样：if rand.Intn(100) == 0 { log.Printf("...") } - 关键指标（如每分钟被限次数）用 Prometheus 的
Counter上报，不要依赖日志 grep - 别在限流中间件里调用外部服务（如发告警），失败或超时会卡住整个请求链路
真正难的不是写限流代码，而是确定哪些接口该限、限多少、依据什么数据调整——这些得靠线上监控和业务反馈持续迭代，代码只是执行载体。
