直接用 time.Sleep 做限速在并发下失效，因其仅阻塞当前 goroutine，无法约束其他 goroutine；多个并发调用时 QPS 远超预期，且普通闭包变量存在竞态，必须结合原子操作与时间窗口校准实现并发安全限速。
为什么直接用 time.Sleep 做限速在并发下会失效
因为 time.Sleep 只阻塞当前 goroutine，不控制其他 goroutine 的执行节奏；多个并发调用时，实际 QPS 会远超预期。比如你写了个每秒最多 10 次的限速函数，但 100 个 goroutine 同时调用，它照样全放行——根本没共享状态约束。
闭包能封装一个共享的计数器 + 时间窗口，但单纯闭包+普通变量（如 count int）依然不安全：多个 goroutine 读写同一变量会竞态。必须配合同步机制。
- 别用
var count int+ 闭包，这是常见误用 - 别依赖「逻辑上只该一个 goroutine 调用」这种假设——生产环境没人帮你守这个契约
- 真正并发安全的限速，核心是「原子操作 + 时间窗口校准」，不是「延迟一下」
用 sync/atomic 和时间戳实现轻量级固定窗口限速
固定窗口（Fixed Window）最易理解：每秒重置一次计数器。用 atomic.Int64 存当前计数，再用 atomic.LoadInt64 / atomic.AddInt64 保证读写原子性。关键是要把「窗口起始时间」也存下来，并在每次调用时检查是否跨窗。
func NewFixedWindowLimiter(max int64, window time.Duration) func() bool {
var count atomic.Int64
var windowStart atomic.Int64
now := time.Now().UnixNano()
windowStart.Store(now)
return func() bool {
ts := time.Now().UnixNano()
windowEnd := windowStart.Load() + int64(window)
if ts > windowEnd {
// 跨窗：重置计数器和窗口起点
count.Store(0)
windowStart.Store(ts)
}
c := count.Add(1)
return c <= max
}
}
- 注意
windowStart必须用atomic.Int64，否则多 goroutine 下可能读到旧值导致窗口错位 - 这里没锁，靠原子操作和时间戳判断实现无锁限速，适合低延迟场景
- 缺点：窗口边界处会出现“突增”，比如 0.999s 到 1.001s 之间可能放行 2×max 次
用 golang.org/x/time/rate 替代手写闭包更稳妥
标准库扩展包 rate.Limiter 内部基于令牌桶（Token Bucket），支持平滑限速、支持阻塞/非阻塞模式、自带并发安全，且经过长期验证。自己手写闭包限速，除非有极特殊需求（比如嵌入式资源受限），否则没必要。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
rate.NewLimiter(rate.Limit(10), 1)表示每秒 10 个令牌，初始 1 个 -
limiter.Allow()非阻塞判断是否允许；limiter.Wait(ctx)阻塞等待令牌 - 注意：
rate.Limit单位是「每秒次数」，不是「间隔毫秒」，别传rate.Limit(100)想表达「每 100ms 一次」——那是错的 - 它的底层用
sync.Mutex+ 精确时间计算，比手写原子操作更鲁棒，尤其在高并发、长时间运行时
闭包限速函数里最容易漏掉的初始化陷阱
闭包捕获外部变量时，如果该变量是结构体或指针，容易误以为「每个闭包实例独立」。实际上，若闭包由同一个工厂函数生成，它们共享同一份底层状态——除非你显式为每次调用分配新结构。
- 错误示范：
func newLimiter() func(){ c := &counter{}; return func(){c.inc()} }—— 多次调用newLimiter()返回的闭包仍共用同一counter实例 - 正确做法：闭包内所有状态必须在每次工厂调用时新建，或用
sync.Pool管理（但 Pool 本身要配好 New 函数） - 更隐蔽的问题：用
time.Now().Second()当窗口 key，会导致整秒内所有请求落到同一个窗口——但Second()返回的是秒级整数，精度丢失严重
真正上线前，至少跑一轮 go test -race，别信「我这个逻辑很简单不会出问题」。限速失效往往不是崩，而是悄悄超发，等压测或上线才暴露。
