golang.org/x/time/rate 是官方维护的轻量限流方案，基于漏桶模型，需全局复用 limiter 实例而非每次新建；令牌生成必须用 crypto/rand（如 google/uuid），禁用 math/rand；限流应在认证前，注意中间件顺序、上下文传递和时钟漂移影响。
限流用 golang.org/x/time/rate 就够了，别自己造轮子
标准库没有限流，但 x/time/rate 是官方维护、生产验证过的轻量方案，不是第三方库。它基于漏桶（Leaky Bucket）模型，rate.Limiter 实例线程安全，可复用，无需额外同步。
常见错误是把 rate.NewLimiter 放在 HTTP handler 里每次新建——这会导致限流失效，因为每个请求都拿到独立的 limiter 实例。正确做法是定义包级或结构体字段级变量：
var apiLimiter = rate.NewLimiter(rate.Limit(100), 200) // 100 QPS，初始桶容量 200
func handleAPI(w http.ResponseWriter, r *http.Request) {
if !apiLimiter.Allow() {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
// ...
}
-
rate.Limit(100)表示每秒最多允许 100 次调用，不是“每 100ms 一次” - 第二参数是 burst（突发容量），设为 0 会立即拒绝所有超限请求；设为 200 表示允许最多积压 200 次请求等待匀速释放
- 若需按 IP 或用户 ID 区分限流，请用 map + sync.Map 缓存 limiter，键为标识符，注意定期清理过期项（比如用
time.AfterFunc或 LRU 策略）
分布式令牌生成必须用 github.com/google/uuid + crypto/rand，别用 math/rand
标准库 math/rand 是伪随机，种子固定时输出可预测；分布式场景下，令牌一旦被猜出或批量生成，就等于绕过鉴权。真正安全的令牌必须依赖操作系统熵源。
google/uuid 默认使用 crypto/rand（Linux 下读 /dev/urandom，Windows 调用 BCryptGenRandom），生成的 v4 UUID 具备密码学安全性，且无中心协调成本：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
import "github.com/google/uuid"
func generateToken() string {
return uuid.NewString() // 返回 32 字符小写 hex，如 "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"
}
- 不要用
uuid.Must(uuid.NewUUID())—— 它 panic 的条件（熵不足）在容器或嵌入式环境可能真实发生，应显式处理 error - 若需要更短或自定义格式（如 16 字符 base62），请基于
crypto/rand.Read()自行构造，但务必避免截断 UUID 或移除校验位 - Redis 存储令牌时建议加 TTL（如
SETEX token:abc123 3600 "user:123"），避免无限累积
限流与令牌组合时，注意中间件顺序和上下文生命周期
HTTP 中间件顺序决定行为逻辑：限流应在认证前，否则攻击者可绕过限流反复试探无效令牌；令牌校验应在限流后，否则无效请求也消耗配额。
- 典型顺序：
RateLimit → Auth → Handler，而非Auth → RateLimit → Handler - 用
context.WithValue传令牌解析结果，但别把整个*http.Request塞进 context——容易引发内存泄漏；只存必要字段如userID、scope - 如果用 Gin/Echo，别在中间件里直接
w.WriteHeader()后继续执行 handler；应统一用return退出链路
本地开发时别忽略时钟漂移对限流精度的影响
rate.Limiter 内部依赖系统单调时钟（time.Now()），但在 Docker 容器或 WSL 中，宿主机休眠唤醒后可能出现时间跳变，导致 limiter 突然“多放行”一批请求。
- 生产环境务必启用 NTP 同步（如
systemd-timesyncd或chrony） - 测试时可用
docker run --cap-add=SYS_TIME允许容器调整时间，模拟漂移场景 - 高敏感服务（如支付回调）建议叠加 Redis 计数器做二次校验，用
INCR + EXPIRE原子操作，不依赖本地时钟
限流和令牌看似简单，但组合使用时的时序、作用域和环境假设才是出问题的地方。尤其当模块要复用到多个服务时，把 limiter 实例化位置和 token 生成路径写死在某处，比算法本身更容易埋雷。
