直接用 time.ticker 做令牌桶会出错，因其固定节奏注入无法应对突发流量；正确做法是闭包封装状态，每次调用时用 time.now() 动态计算 elapsed.seconds()*rate 补充令牌，并与容量取 min，注意 float64 精度和比较方式。
为什么直接用 time.Ticker 做令牌桶会出错
很多人一上来就用 time.Ticker 每秒往桶里塞一个令牌，但这样无法应对突发流量——Ticker 是固定节奏的，而真实场景中请求可能在某毫秒内密集到达，此时桶里没令牌就直接拒绝，哪怕下一毫秒才该补满。令牌桶的核心是「按需匀速生成」，不是「定时批量注入」。
闭包的作用，就是把当前桶的状态（剩余令牌数、上次更新时间）封在函数内部，每次调用时动态计算应补充多少令牌，再判断是否够用。
- 必须用
time.Now()计算真实经过时间，不能靠计数器或固定间隔累加 - 令牌补充公式是：
tokens += elapsed.Seconds() * rate，结果要和桶容量取min - 注意浮点精度：用
float64存令牌数，比较时别用== 0，改用tokens
func() bool 闭包限流器怎么写才线程安全
Go 的 goroutine 很多，多个请求同时调用同一个限流器时，必须保证对桶状态的读写是原子的。别想着用 sync.Mutex 包一层就完事——锁粒度太大会拖慢吞吐，而单纯用 atomic 又难处理「读-改-写」这种复合操作。
最简稳解是：把状态封装进结构体，用 sync.Mutex 锁住整个 Take 方法，但只锁必要部分；闭包只是返回这个方法的绑定版本，不参与同步逻辑。
func NewTokenBucket(capacity int, rate float64) func() bool {
var (
mu sync.Mutex
tokens = float64(capacity)
last = time.Now()
)
return func() bool {
mu.Lock()
defer mu.Unlock()
now := time.Now()
elapsed := now.Sub(last)
tokens += elapsed.Seconds() * rate
if tokens > float64(capacity) {
tokens = float64(capacity)
}
last = now
if tokens
- 闭包捕获的是变量地址，不是值，所以多个 goroutine 调用的是同一套状态
- 不要在闭包外暴露
tokens或last，否则破坏封装 - 别用
time.Sleep在闭包里等令牌——这会让 goroutine 阻塞，应该由调用方决定是否重试或返回错误
如何让限流器支持「预占」和「回退」能力
有些场景需要先检查是否有足够令牌（比如预估后续操作成本），或者执行失败后归还已扣减的令牌。纯布尔返回的闭包做不到这点，得升级接口。
典型做法是把闭包改成接收参数的函数，比如 func(n int) bool 表示尝试获取 n 个令牌；再加一个 func(n int) 回退函数。但注意：回退必须校验是否真扣过，否则可能超发。
- 记录每次扣减前的
tokens值，回退时只允许退到该快照值 - 如果用
float64表示令牌，n应该是float64类型，避免整数除法丢失精度 - 「预占」建议用
func(n float64) (bool, float64)，返回是否成功 + 当前剩余数，方便调用方做决策
为什么不用第三方库（如 golang.org/x/time/rate）而手写闭包
rate.Limiter 确实好用，但它默认行为是阻塞等待（Wait）或立即返回（Allow），且内部用 atomic 实现，状态不可观察。当你需要：实时查看剩余令牌数、按不同权重消耗令牌（比如大文件上传扣 3 个，小请求扣 1 个）、或和外部指标系统联动时，它的抽象层反而成了障碍。
闭包的优势在于轻量、可控、无依赖。只要把核心逻辑（时间推算 + 令牌增减 + 边界检查）封进函数，就能嵌入任意上下文——HTTP 中间件、RPC 拦截器、甚至 CLI 工具的命令执行前钩子。
- 别为了“看起来高级”而硬套闭包；如果只需要简单每秒 100 请求，
rate.NewLimiter(100, 1)更可靠 - 手写闭包真正有价值的场景是：需要自定义令牌计算逻辑（比如按请求大小线性扣费）、或必须与现有状态机耦合
- 上线前务必压测：高并发下
sync.Mutex锁争用是否成瓶颈？考虑用sync.Pool缓存临时对象，但别过早优化
闭包本身不解决并发问题，它只是把状态和行为绑在一起的手段；真正决定限流效果的，是时间计算的准确性、锁的范围、以及对浮点误差的容忍方式。
