直接用 time.AfterFunc 做限流会出问题，因为它只触发一次、无法动态调整速率或取消已排队调用，且不维护状态、无“当前是否允许执行”判断接口；限流需可重入可复位的状态管理，闭包恰好能封装 limit、windowStart、count 三个变量实现轻量级线程安全限流。
为什么直接用 time.AfterFunc 做限流会出问题
因为 time.AfterFunc 只触发一次，无法动态调整速率或取消已排队的调用；它不维护状态，也不提供“当前是否允许执行”的判断接口。限流本质是控制单位时间内的调用次数，需要可重入、可复位的状态管理，闭包恰恰能封装这个状态。
闭包限流器的核心结构怎么组织
一个可用的限流器闭包必须捕获三个关键变量：limit（每秒允许请求数）、windowStart（当前窗口起始时间）、count（当前窗口内已处理请求数）。每次调用时检查是否在窗口内、是否超限，超限则阻塞或拒绝。
- 用
time.Now().UnixNano()做时间戳，避免浮点运算和时区干扰 - 窗口大小固定为 1 秒，但可通过参数化改成任意
time.Duration - 不依赖外部锁（如
sync.Mutex），而是靠闭包变量 + 原子操作或简单条件判断实现轻量级线程安全 - 返回函数类型为
func() bool，返回true表示放行，false表示被限流
带超时的限流器怎么写才不会卡死
超时控制不是加个 select 就完事——如果只对单次调用加超时，可能让限流逻辑失效（比如等不到窗口重置就超时返回，下次调用又从头计数）。正确做法是把“等待窗口重置”本身纳入超时范围。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
time.After配合select等待窗口重置，但需在等待前计算剩余等待时间：resetAt.Sub(time.Now()) - 若剩余等待时间 ≤ 0，说明窗口已过期，直接重置
count = 1、windowStart = now - 若等待超时（比如设置 500ms 超时），则返回
false，不消耗配额，也不更新状态 - 不要在闭包里启动 goroutine 去“定时重置”，这会导致状态竞争和内存泄漏
func NewRateLimiter(limit int) func() bool {
var count int
var windowStart int64 = time.Now().UnixNano()
return func() bool {
now := time.Now().UnixNano()
windowSize := int64(time.Second)
if now-windowStart >= windowSize {
count = 0
windowStart = now
}
if count < limit {
count++
return true
}
return false
}
}
真实场景下容易漏掉的边界条件
限流器跑在高并发 HTTP handler 里时，最常踩的坑不是逻辑错，而是时间精度和整数溢出。
立即学习“go语言免费学习笔记（深入）”；
-
UnixNano()返回 int64，但频繁调用下，如果窗口大小设成 1ns，几秒就溢出——必须确保windowSize远大于最小时间单位 - 多个 goroutine 同时调用闭包函数，
count++非原子，实际使用必须加sync/atomic或用sync.Mutex包裹（闭包变量本身不能保证并发安全） - 测试时用
time.Sleep模拟延迟，但它的精度在毫秒级，可能导致“看似没超限却失败”，建议用time.Now().Add()手动推进时间做单元测试 - HTTP 中间件里直接用该闭包，会共享同一个限流状态，若需 per-user 限流，得用 map + sync.RWMutex 管理多个闭包实例，而不是一个全局闭包
闭包让状态封装变简单，但也容易让人忽略它背后仍是共享变量——并发安全从来不是闭包自动带来的，得自己兜住。
