time.Ticker 不适合直接做请求限频，因其按固定节奏触发且不感知请求时间，无法实现“最近1秒内最多N次”的动态限流，易在突发流量下漏放或误拦；应使用golang.org/x/time/rate令牌桶实现。
为什么 time.Ticker 不适合直接做请求限频
因为 time.Ticker 是固定节奏“滴答”，不感知请求到来时间，容易在突发流量下漏放或误拦。比如你设了每秒 10 次，但请求集中在某毫秒内涌来，time.Ticker 仍只 tick 一次，无法拦截超额请求。
它本质是定时器，不是计数器——别把它当 rate.Limiter 用。
- 真实场景要的是“最近 1 秒内最多 10 次”，不是“每秒固定给 10 个令牌”
-
time.Ticker.C是只读通道，不能塞请求、不能回退、不能重置 - 若强行用
select配合default判断是否可执行，会丢失精度：两次 tick 之间的时间窗口无法计量
用 golang.org/x/time/rate 替代的实操要点
标准库没提供开箱即用的限频器，但官方扩展包 rate 是事实标准，基于“令牌桶”，支持平滑限流和突发容忍。
- 初始化：
limiter := rate.NewLimiter(rate.Every(time.Second/10), 10)表示“每 100ms 放 1 个令牌，桶容量 10” - 检查是否允许：
if limiter.Allow() { /* 处理请求 */ }—— 简单，但不阻塞 - 想等令牌就用：
if err := limiter.Wait(ctx); err != nil { /* 超时或取消 */ } - 注意：
Allow()和Wait()都是并发安全的，不用额外加锁
自己手写简单令牌桶时，time.Now() 和 time.Since() 怎么用才不出错
手动实现的核心是维护上次填充时间和当前令牌数，关键在于时间计算必须单调、不依赖系统时钟跳变。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 别用
time.Now().UnixNano()做差值比较——NTP 校正可能导致负差 - 统一用
time.Since(lastTime)，它底层调用单调时钟（monotonic clock） - 每次请求来，先算间隔：
elapsed := time.Since(l.lastRefill)，再按速率补令牌：newTokens := float64(l.rate) * elapsed.Seconds() - 记得截断：令牌数不能超过桶容量，且浮点累加易有误差，建议用
math.Min()或整型计数 + 时间戳分段
HTTP 中间件里嵌 rate.Limiter 的常见坑
限频逻辑放在中间件里很自然，但几个细节不注意就会失效或拖慢整个服务。
- 每个用户/IP 应该有自己的
rate.Limiter实例，别全用一个全局变量——否则所有请求共享同一桶 - 用
sync.Map缓存 limiter 实例时，注意 key 是字符串（如r.RemoteAddr），避免重复 new - 别在
http.HandlerFunc里每次都rate.NewLimiter(...)，构造成本低但 GC 压力大，且丢失状态 - 测试时用
httptest.NewRequest+WithContext注入带 deadline 的 ctx，验证Wait()超时行为
真正难的不是写对一次限频，而是让不同用户、不同路径、不同优先级的请求互不干扰，又不因锁或 map 查找拖慢高频接口——这些得靠压测和 pprof 看出来，光看代码看不出问题。
