单机限速用 rate.limiter 足够，需合理设置 limit 和 burst（通常为平均 qps 的 2–3 倍）；多实例需分布式限流如 redis 或 etcd；http 中间件中应尽早归一化 key 并避免误限流；限流、熔断、降级职责分离，不可混用。
用 golang.org/x/time/rate 实现单机请求限速
绝大多数微服务场景下，单节点限速用 rate.Limiter 就够了，它轻量、无依赖、线程安全。核心是控制每秒允许通过的请求数（rate.Limit）和令牌桶容量（burst）。
常见错误是把 burst 设得过大，导致突发流量瞬间打穿下游；或者设为 1，又让正常抖动都被拒绝。合理值通常取平均 QPS 的 2–3 倍，比如平均 50 QPS，burst 可设为 100–150。
示例用法：
limiter := rate.NewLimiter(50, 100) // 每秒 50 个令牌，最多积压 100 个
if !limiter.Allow() {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
-
Allow()是非阻塞判断，适合 HTTP 中间件快速响应 - 需要等待时可用
Wait(ctx)，但注意别让超时时间过长，否则堆积 goroutine - 不要在每个 handler 里新建
Limiter，应作为全局变量或 per-service 实例复用
跨实例限速必须引入分布式限流组件
单机 rate.Limiter 在多副本部署下完全失效——每个实例各自计数，总流量是副本数 × 限速值。真要控总量，得用中心化存储或一致性哈希协调。
立即学习“go语言免费学习笔记（深入）”；
常用方案有三种：
- 基于 Redis + Lua：用
INCR+EXPIRE原子实现滑动窗口，推荐使用github.com/bsm/redislock或直接封装redis-go调用 - 基于 etcd：利用
CompareAndSwap和租约（lease）做带过期的计数器，适合已用 etcd 做服务发现的架构 - 用专用限流服务如 Sentinel Go 版，但会增加运维复杂度和网络跳数，小团队慎选
关键点：所有节点必须共享同一 key 命名空间，例如按 service:api_user_get:{user_id} 细粒度限流，而不是笼统的 service:api_user_get。
HTTP 中间件中嵌入限流逻辑的典型陷阱
很多人把限流写在中间件里，却忽略了路径参数提取、header 解析、以及限流 key 的动态构造方式，结果导致限流失效或误杀。
常见问题包括：
- 用
r.URL.Path当 key，没处理带查询参数的 URL，导致相同接口不同参数被当成不同请求分散计数 - 未标准化路径，比如
/users/123和/users/456应归为/users/{id}才能按用户维度限流 - 忽略 header 中的
X-Forwarded-For或Authorization，无法实现按用户/IP 限流 - 在限流判断前就调用
r.ParseForm()，可能因恶意大 body 导致阻塞，应先限流再解析
建议用 chi/middleware 或自定义中间件，在 http.Handler 入口尽早提取并归一化 key，再查限流器。
限流与熔断、降级的协同边界在哪
限流（rate limiting）只管“进来的请求数量”，不关心下游是否健康；而熔断（如 sony/gobreaker）看的是失败率和延迟；降级是主动关闭非核心功能。三者常被混用，但触发条件和作用域完全不同。
典型误用：
- 用限流代替熔断：下游已超时或 5xx 高发，还在放行请求，只会加剧雪崩
- 在限流中间件里直接返回 mock 数据（降级行为），破坏了职责分离，后续难调试和监控
- 对数据库查询做 per-request 限流，不如在 DAO 层用连接池 + context timeout 控制更有效
真正健壮的流量控制，是限流守入口、熔断护下游、降级保主干——它们该在不同层级生效，且指标采集来源也应隔离。
限流最容易被忽略的其实是“动态配置能力”：硬编码的 rate.Limit 值在线上遇到活动或故障时根本来不及改，必须支持从配置中心热加载，哪怕只是简单的文件监听或环境变量轮询。
