Go微服务限流核心是用令牌桶算法控制QPS，推荐golang.org/x/time/rate实现；支持按用户/IP/路径差异化限流，需用sync.Map缓存独立限流器并设过期策略；集成Gin等框架时应配置化、加监控指标与标准响应头，避免误限健康检查端点。

在 Go 微服务中实现限流，核心是控制单位时间内接口的请求数量，防止突发流量压垮下游服务或数据库。常用且实用的方式是结合 令牌桶（Token Bucket） 或 漏桶（Leaky Bucket） 算法，用轻量、无依赖、线程安全的方案落地。

使用 golang.org/x/time/rate 实现简单限流

Go 标准库扩展包 golang.org/x/time/rate 提供了开箱即用的令牌桶实现，适合大多数 HTTP 接口级限流场景。

• 创建一个 rate.Limiter 实例，指定每秒放行的请求数（QPS）和最大突发容量（burst）
• 在 HTTP handler 中调用 limiter.Allow() 或 limiter.Wait() 判断是否允许请求通过
• 推荐用 Allow() 做快速拒绝（返回 429 Too Many Requests），避免阻塞

示例：

func rateLimitMiddleware(limiter *rate.Limiter) http.Handler {
  return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    if !limiter.Allow() {
      http.Error(w, "Too many requests", http.StatusTooManyRequests)
      return
    }
    next.ServeHTTP(w, r)
  })
}

按用户/IP/接口路径做差异化限流

单一全局限流粒度太粗，实际中常需区分来源。可通过中间件提取标识（如 X-User-ID、X-Real-IP 或路由 path），为每个标识维护独立的限流器。

• 用 sync.Map 缓存各 key 对应的 *rate.Limiter，避免重复创建
• 设置合理的过期策略（如 1 小时未访问自动清理），防止内存泄漏
• 注意高并发下 Map 的写竞争，建议用读多写少模式，或搭配 sync.RWMutex

关键逻辑示意：

集成到 Gin / Echo 等框架的实践方式

以 Gin 为例，可封装成中间件，支持配置化限流规则：

• 定义结构体承载 QPS、burst、key 生成函数等参数
• 在 middleware 中动态解析 key，获取或新建对应限流器
• 配合 Prometheus 暴露 http_requests_limited_total 指标，便于监控告警

进阶可对接 Redis 实现分布式限流（如基于 Lua 脚本的原子计数），适用于多实例部署场景，但会引入额外延迟和运维成本。

注意边界与可观测性

限流不是“加个中间件就完事”，还需关注真实效果：

• 记录被限流的请求日志（含 key、时间、客户端 IP），用于分析异常调用方
• 响应头中添加 X-RateLimit-Limit、X-RateLimit-Remaining 等标准字段，提升 API 可用性
• 避免对健康检查、metrics 端点限流，可在中间件中白名单过滤

不复杂但容易忽略。真正有效的限流，是策略+工具+观测三者闭环。