Allow总是返回false是因为未调用Wait/Reserve且未推进时间，它仅瞬时检查当前令牌数；初始化后若limit和burst过小（如rate.Every(1*time.Second)+burst=1），首次调用即失败。
为什么 rate.Limiter 的 Allow 总是返回 false？
因为没调用 Wait 或 Reserve，也没主动重置时间基准——Allow 是纯瞬时判断：当前时刻桶里有没有可用令牌。如果初始化后立刻调用，且 limit 和 burst 设得小（比如 rate.Every(1 * time.Second) + burst=1），第一次就可能失败。
-
Allow不阻塞、不等待、不补充令牌，只查当前快照 - 想“等令牌”必须用
Wait（会阻塞）或Reserve（返回rate.Reservation，需手动Delay后再OK） - 测试时别用
time.Sleep(10ms)就以为过了 100ms——真实间隔受调度影响，建议用time.Now().Add模拟时间推进，或直接测Wait
rate.NewLimiter 的三个参数怎么配才不踩坑？
rate.NewLimiter(r rate.Limit, b int) 中的 r 是每秒令牌生成速率（float64），b 是初始桶容量。常见误配：
-
r = 0.1表示每 10 秒 1 个令牌，不是“每分钟 6 个”——Go 的rate.Limit单位恒为 “个/秒”，别自己换算错 -
b < r没问题，但若b == 0，首次Allow必然失败（桶空），且后续所有请求都得等第一个令牌生成，实际等于完全限流 - 高并发下
b太小会导致突发流量被大量拒绝；太大又失去限流意义——推荐设为期望峰值 QPS × 2~3 秒，例如目标 100 QPS，b = 250
如何让 rate.Limiter 支持 per-IP 或 per-user 粒度？
标准 rate.Limiter 本身无上下文，必须外挂映射结构。注意并发安全与内存泄漏：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
sync.Map存map[string]*rate.Limiter，key 是 IP 或 user ID；不要用普通map+ 全局锁，写多时成瓶颈 - 必须限制 limiter 实例总数，否则恶意构造新 key 可耗尽内存——加 LRU 或 TTL 清理，例如用
github.com/hashicorp/golang-lru/v2包 - 别在 HTTP handler 里每次 new 一个 limiter：既慢又失控；应复用已有实例，或用带过期的池化方式
- 示例判断逻辑：
if !limiter.Allow() { http.Error(w, "too many requests", http.StatusTooManyRequests); return }
为什么压测时 Wait 阻塞时间远超预期？
因为 rate.Limiter.Wait 的等待时长 = 缺少的令牌数 ÷ 速率，且基于系统单调时钟计算。典型偏差来源：
立即学习“go语言免费学习笔记（深入）”；
- 桶中剩余令牌为负数时（如 burst=1，连续两次请求），第二次需等满 1/r 秒，而非“补 1 个就走”
- 如果用
time.Sleep模拟客户端延迟，而服务端 CPU 负载高，Wait内部的time.Until计算仍准，但 goroutine 调度延迟会让实际挂起更久 - 避免在循环里反复调用
Wait而不检查错误——它可能返回context.Canceled，尤其你传了带 cancel 的 context
真正难的不是创建一个 rate.Limiter，而是决定哪个请求该放行、哪个该拒掉，以及拒掉之后要不要记录、告警、降级——这些逻辑不会出现在 x/time/rate 里。
