golang.org/x/time/rate仅支持单机限流，无法应对微服务多实例、动态扩缩容场景，因限流状态不共享导致全局速率失控；分布式限流必须依赖Redis+Lua实现原子操作，并做好降级与key精确设计。
为什么直接用 golang.org/x/time/rate 在微服务里不够用
因为 rate.Limiter 是单机内存态，服务一扩缩容或重启，限流状态就丢；微服务通常部署在多实例、动态调度环境（比如 Kubernetes），靠本地计数器根本没法保证全局速率一致。你看到的“限流生效”，很可能只是某台机器压测时的假象。
常见错误现象：429 Too Many Requests 响应忽高忽低，压测时部分实例被打爆，另一些却空闲；灰度发布后限流阈值突然变化。
- 别把
rate.NewLimiter当成全局限流器塞进 HTTP 中间件——它只管当前 goroutine 所在进程 - 若用 Redis 实现分布式限流，必须处理
redis.Nil、网络超时、pipeline 原子性等边界情况，不是简单INCR + EXPIRE - Kubernetes Service 的 ClusterIP 模式下，客户端直连 Pod，不同实例看到的流量分布不均，本地限流会放大这种偏差
用 uber-go/ratelimit 还是 go.uber.org/ratelimit？
两个包名容易混淆，但实际只有 go.uber.org/ratelimit 是 Uber 官方维护、支持并发安全且带滑动窗口语义的轻量库；uber-go/ratelimit 是社区早期 fork，已归档停更。选错会导致 panic：比如调用 Take() 时遇到未初始化的 atomic.Value。
它适合做单机强一致性限流（如 API 网关的 per-route 限流），但注意：它不解决跨进程同步问题，仅作为本地兜底或与中心化存储配合使用。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
ratelimit.New(100, ratelimit.WithSlidingWindow(5))表示 5 秒滑动窗口内最多 100 次请求 - 默认使用
time.Now()，若服务部署在不同 NTP 时间源的节点上，窗口计算可能偏移，建议统一校时 - 它的
Take()是阻塞式，高并发下易堆积 goroutine，生产环境建议搭配 context.WithTimeout 使用
如何用 Redis + Lua 实现可靠的分布式限流中间件
核心是把限流逻辑封装进原子 Lua 脚本，避免 GET + INCR + EXPIRE 的竞态。Redis 官方推荐的令牌桶脚本（rate_limit.lua）需适配 Go 的 redis.UniversalClient 调用方式。
典型错误：直接拼接 key 名称导致命名空间冲突，例如所有服务共用 rl:api:/user/profile，没带上服务名或租户 ID。
- key 设计必须包含唯一标识：
rl:{service_name}:{tenant_id}:{endpoint} - Lua 脚本返回数组，Go 侧要检查
result[0].(int64)是否为 1（允许）或 0（拒绝），不能只看 error - 连接池配置不当（如
MinIdleConns过小）会导致限流本身成为瓶颈，建议设为 CPU 核数 × 2 - 不要在限流失败时直接
return，应记录 metric（如ratelimit_rejected_total{service="auth", endpoint="/login"}）便于排查
Service Mesh 场景下该不该在应用层自己做限流
如果已接入 Istio 或 Linkerd，优先用其内置限流能力（Istio 的 EnvoyFilter + RateLimitService），而不是在 Go 代码里再写一套。重复限流不仅增加延迟，还会让指标口径混乱：Prometheus 里看到的 http_requests_total 和网关层统计对不上。
例外情况：业务有精细控制需求，比如按 JWT 中的 user_tier 字段动态设置 QPS，此时需在应用层解析 token 后调用限流器。
- Istio 默认限流策略无法读取 request body，所以表单提交类接口仍需应用层校验
- Sidecar 限流失败返回的是
429，但错误信息固定，不利于前端区分“被限流”和“系统过载”，可在应用层补充X-RateLimit-Reasonheader - Envoy 的 token bucket 实现和 Go 的
rate.Limiter参数含义不完全一致（比如fill_interval对应 refill rate），迁移时需重新压测校准
rate.Limiter 并打 warning 日志。这个开关是否启用、阈值怎么设，得结合业务容忍度来定。 
