time/rate.Limiter 不会自动阻塞协程，因其默认允许突发（burst），Wait 仅按需等待且依赖 context 控制超时；Allow 非阻塞，Reserve 提供精细控制但需手动处理延迟或取消。
为什么 time/rate 的 Limiter 不会自动阻塞协程
很多人一上来就调 limiter.Wait(ctx)，发现没效果或 panic，其实根本原因是：默认创建的 Limiter 允许“突发”（burst），且 Wait 只在需要时才真正等待——它不强制限流，而是按需调度。你得先理解它的两个核心参数：limit（每秒令牌数）和 burst（桶容量）。比如 rate.NewLimiter(10, 5) 表示每秒最多补充 10 个令牌，但桶里最多存 5 个，超出的请求立刻被拒绝（除非你用 Allow 或 Reserve 显式处理）。
常见错误现象：
– 调了 limiter.Allow() 却发现高并发下还是打满下游
– Wait 返回 nil，但实际没等，误以为被限流了
– 没传带超时的 context，导致协程卡死
-
Allow()是非阻塞的，只看当前有没有令牌，有就消费、返回 true，否则立刻 false —— 它不排队也不等 -
Wait(ctx)才会阻塞，但它依赖context控制等待上限；若 ctx 已 cancel 或 timeout，直接返回 error - 如果想“严格控速”，别用
Allow，改用Wait+ 带 deadline 的 context
如何正确配置 time/rate.Limiter 应对突发流量
令牌桶不是“硬闸门”，burst 参数决定了你能容忍多大的瞬时毛刺。设得太小（比如 burst=1），哪怕 limit=100，也会让前几个请求全过、后面全等；设得太大（比如 burst=1000），等于放任短时洪峰冲垮下游。
使用场景举例：
– API 网关层限流：burst 可设为平均 QPS 的 2~3 倍，给客户端重试留余地
– 内部服务调用：burst 接近 1，强调平滑，避免雪崩传导
立即学习“go语言免费学习笔记（深入）”；
- 初始化时用
rate.Every(d)更安全，比如rate.Every(100 * time.Millisecond)等价于 limit=10，比手算 float64 更不易错 - 不要复用同一个
Limiter实例做差异化限流（如 per-user 和 per-ip），每个策略应独立实例 - 注意：
Limiter是 goroutine-safe 的，但内部状态是原子操作，高频调用下性能损耗可忽略（压测中 100w QPS 下单核 CPU 占用不到 3%）
Reserve 和 Wait 的区别到底在哪
Reserve 不阻塞，它返回一个 *rate.Reservation，你可以检查 OK()、看 Delay() 多久后能执行、甚至手动 Cancel()。而 Wait 就是把这一套封装成“等完再继续”。关键区别在于控制粒度。
典型错误：
– 直接 res := limiter.Reserve() 后就 res.OK() 判断，却忘了调 res.Delay() 延迟执行逻辑，结果时间没对齐，限流失效
– 在 HTTP handler 里用 Reserve 但没 defer Cancel，导致令牌被预占却不消费，桶迅速变空
- 如果要精确控制“某次请求延迟多久再执行”，用
Reserve+time.Sleep(res.Delay()) - 如果只是“不想被拒绝，愿意等”，直接
limiter.Wait(ctx)最简洁 -
Reserve返回的Reservation必须在作用域结束前调Cancel()或执行，否则令牌不会归还（即使 res.OK() == false）
为什么测试时 time.Now() 会影响 time/rate 行为
time/rate 内部用 time.Now() 计算令牌生成时间，所以单元测试里如果 mock 了系统时间（比如用 testify 的 clock 或自己注入 func() time.Time），必须确保 Limiter 也使用同一套时间源——但它不支持传入自定义 clock。
这意味着：标准库 time/rate 在时间敏感测试中天然难 mock。你没法让它“快进 1 秒然后看桶里有几个令牌”。
- 真实项目中，别试图在 UT 里断言“调两次 Allow 中间隔 100ms 就一定成功”，那是集成测试范畴
- 可接受的替代方案：用
Reserve+Delay()测返回值，比测行为更可靠 - 如果真要完全可控，考虑用第三方替代如
golang.org/x/time/rate（注意：它就是标准库的路径，没第三方；真正可选的是github.com/uber-go/ratelimit这类，但会引入额外依赖）
最常被忽略的一点：Limiter 的初始状态是“满桶”，即 new 出来第一秒内所有请求都可能通过，不管 limit 多小。如果你的服务启动后立刻遭遇流量高峰，这个“冷启动突刺”得靠前置 warmup 或外部网关兜底。
