应使用 rate.limiter 的 wait 或 allown 方法触发真实限流，配合主动时间推进和 mockclock 控制时钟，避免 sleep 依赖与竞态误判，确保 burst 设置合理并验证并发请求的令牌获取行为。
用 golang.org/x/time/rate 模拟真实限流行为
令牌桶不是靠 sleep 或 time.After 硬等出来的，必须用 rate.Limiter 的 Wait 或 AllowN 方法触发实际限流逻辑。直接测「时间间隔」容易漏掉并发竞争下的状态漂移。
-
Wait会阻塞直到获得令牌（或上下文超时），适合模拟真实请求等待；AllowN是非阻塞的快照判断，适合做预检但不能验证“排队等待”行为 - 测试中务必用
time.Now+time.Sleep控制时间推进，别依赖系统时钟跳变——rate.Limiter内部用的是单调时钟，但你的测试逻辑得主动“拨动时间” - 初始化
rate.NewLimiter时，burst要设够：比如rate.Every(100 * time.Millisecond)配burst=2，才能测出第 3 个请求被限流
并发 goroutine 下测 AllowN 返回 false 的时机
多个 goroutine 同时调 AllowN 会暴露竞态，但标准库的 rate.Limiter 是线程安全的——问题往往出在你没控制好「请求到达时间」。
- 不要用
go f()然后立刻检查结果；加time.Sleep(1 * time.Nanosecond)或用sync.WaitGroup+ 时间戳记录，确保你知道每个请求的「逻辑到达时刻」 - 注意
AllowN的第二个参数是「需消耗令牌数」，传1和2行为完全不同；burst=1 时，连续两个AllowN(1)可能都返回 true（第一个拿走 token，第二个因 burst 允许瞬时透支） - 错误现象：所有请求都返回 true —— 很可能是测试代码没真正并发，或者
burst设置过大掩盖了限流
替换真实时钟做可预测的时间控制
标准 rate.Limiter 依赖 time.Now，导致测试不可控。用依赖注入方式把时钟抽成接口，比 patch time.Now 更可靠。
- 定义
type Clock interface { Now() time.Time }，让rate.Limiter封装层接受它；测试时传入一个可进时间的MockClock - 避免用
monkey.Patch等运行时 patch 工具：它们在 go test -race 下可能失效，且和 module cache 冲突 - 简单场景下，可用
rate.NewLimiter(rate.Limit(10), 1)+time.Sleep组合逼近，但要注意 Go 调度器对小 sleep（
验证「突发流量后是否恢复」的关键断言点
令牌桶的核心价值是抗突发，但多数测试只盯住“限流生效”，忽略“恢复能力”。重点看两次突发之间的 token 是否真正补满。
立即学习“go语言免费学习笔记（深入）”；
- 第一次发 5 个请求（burst=3），前 3 个通过，后 2 个失败；等 300ms 后再发 1 个请求 —— 它应该通过，因为按
rate.Every(100ms)已补满 3 个 token - 别只 assert
AllowN返回值；用lim.Burst()和内部未公开字段无关，正确方式是多次调AllowN(1)并记录成功次数 - 容易踩的坑：用
Reset或重建 limiter 来“重置测试状态”——这绕过了真实场景中的持续 token 积累逻辑，测不出恢复缺陷
真正的难点不在写断言，而在于让多个 goroutine 的请求时间戳和 limiter 内部的「上次取 token 时间」对齐；哪怕差几百纳秒，都可能让预期中的阻塞变成立即拒绝，或反之。
