Token Bucket适合突发流量平滑处理，滑动窗口更精准控制单位时间请求数；两者可组合使用：网关层用Token Bucket做粗粒度保护，业务层用滑动窗口做细粒度控制。
在 Go 微服务中实现限流，核心是平衡系统稳定性与用户体验。Token Bucket 适合突发流量平滑处理，滑动窗口更精准控制单位时间请求数——两者不互斥，可按场景组合使用。
Token Bucket：简单高效，抗短时突发
令牌桶模型维护一个固定容量的“桶”，以恒定速率向桶中添加令牌，每个请求消耗一个令牌；桶满则丢弃新令牌，无令牌则拒绝请求。它天然支持突发流量（只要桶里有余量），实现轻量、无状态，适合网关层或单机限流。
推荐用 golang.org/x/time/rate 包：
- rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示每 100ms 放 1 个令牌，初始桶容量为 5 —— 即允许最多 5 次瞬时请求
- 在 HTTP handler 中调用 limiter.Allow()（非阻塞）或 limiter.Wait(ctx)（阻塞等待令牌）
- 注意：该 limiter 是 goroutine-safe 的，但默认不跨进程共享；若需集群级限流，需配合 Redis + Lua 实现分布式令牌桶
滑动窗口：精确控频，适合统计类限流
滑动窗口将时间划分为小格（如 1 秒分 10 格，每格 100ms），只统计当前窗口内所有格子的请求数之和。相比固定窗口，它避免了临界突增问题（如 0:59.9s 到 1:00.1s 的两个请求不会被算作同一秒的 2 次）。
立即学习“go语言免费学习笔记（深入）”；
Go 中可手写轻量实现：
- 用 sync.Map 存储时间戳 → 计数，定期清理过期 key（或用带 TTL 的 LRU cache）
- 更稳妥做法是用 Redis ZSET：每次请求 ZADD key timestamp timestamp，再 ZCOUNT key (now-60 now] 统计最近 60 秒请求数
- 关键细节：窗口粒度越小，内存/Redis 压力越大；建议 1s 窗口配 10~100 个槽位，兼顾精度与开销
生产建议：分层+降级+可观测
真实微服务中，限流不是“开了就行”，而要融入整体稳定性体系：
- 网关层用 Token Bucket 做粗粒度保护（如 /api/user/* 全局 QPS ≤ 1000）
- 业务层用滑动窗口做细粒度控制（如用户 ID 维度每分钟 ≤ 60 次调用）
- 限流触发时返回标准错误码（如 429 Too Many Requests）和 Retry-After 头，便于客户端退避
- 所有限流事件打日志 + 上报 metrics（如 Prometheus counter http_requests_limited_total{route="user_get",reason="token_bucket"}）
基本上就这些。Token Bucket 上手快、开销低；滑动窗口精度高、逻辑稍重。选哪个不取决于技术炫酷，而看你的延迟敏感度、数据一致性要求和运维能力。
