闭包捕获变量是引用而非副本，导致并发修改不安全，需加锁或原子操作；循环中创建闭包会共享同一变量，应传参或定义新局部变量；闭包延长变量生命周期但非永久，未清理可能引发内存泄漏。
闭包捕获的变量是引用，不是副本
Go 闭包捕获的是变量的地址，只要闭包还活着，这些变量就不会被 GC 回收。限流器里用 tokens、lastRefill 这类状态变量时，必须清楚：多个调用共享同一份内存。比如下面这个常见写法：
func NewLimiter(burst int, refill time.Duration) func() bool {
tokens := burst
lastRefill := time.Now()
return func() bool {
now := time.Now()
elapsed := now.Sub(lastRefill).Seconds()
tokens = min(burst, tokens + int(elapsed/refill.Seconds()))
lastRefill = now
if tokens > 0 {
tokens--
return true
}
return false
}
}这段代码在单 goroutine 下能跑通，但并发调用就会出错——tokens 和 lastRefill 是共享的，没加锁就修改，结果不可预测。
- 闭包状态天然不线程安全，必须显式加锁（如
sync.Mutex）或改用原子操作 - 如果状态只读（比如配置参数），可以放心捕获；但只要涉及写，就得考虑并发
- 别指望“每次调用外层函数就自动隔离”，那是对闭包实例的理解，不是对变量生命周期的理解
每次调用外层函数生成独立闭包实例
限流器要支持不同接口、不同阈值，就得为每个业务函数配专属限流器。靠闭包工厂函数就能做到状态隔离：
limiterA := NewLimiter(5, 100*time.Millisecond) limiterB := NewLimiter(10, 200*time.Millisecond)
这两个闭包各自维护自己的 tokens 和 lastRefill，互不影响。这是闭包比全局变量或单例结构体更干净的地方——不用手动管理实例 ID 或 map key。
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 不要把限流器做成全局单例，否则所有函数共用一个桶，互相挤占额度
- 也不要每次调用都
new一个新限流器（比如在 handler 里直接rate.NewLimiter(...)），那等于没限流 - 推荐把限流器作为依赖注入到 handler 或 service 层，生命周期与业务逻辑对齐
闭包里不能直接捕获循环变量
批量创建限流器时容易掉进循环陷阱。比如想给一组 API 路径分别配限流器：
for _, path := range paths {
limiter := NewLimiter(3, time.Second)
mux.HandleFunc(path, func(w http.ResponseWriter, r *http.Request) {
if !limiter() { // ❌ 所有 handler 共享最后一个 limiter 实例
http.Error(w, "rate limited", http.StatusTooManyRequests)
return
}
// ...
})
}这里 limiter 在循环中被重复赋值，最终所有 handler 捕获的是同一个 limiter 地址。正确做法是立即传参绑定：
for _, path := range paths {
limiter := NewLimiter(3, time.Second)
mux.HandleFunc(path, func(lim func() bool) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
if !lim() {
http.Error(w, "rate limited", http.StatusTooManyRequests)
return
}
// ...
}
}(limiter))
}- 闭包捕获的是变量名，不是当前值；循环变量
limiter只有一个，最后指向最后一次迭代的结果 - 解决方式只有两种：用参数传入当前值，或在循环内定义新局部变量并立即使用
- 这类问题不会报错，但限流行为完全失效，线上很难排查
闭包状态生命周期比外层函数长，但不等于永久
闭包延长了变量的生命周期，但不意味着它永远驻留内存。只要闭包本身被 GC 掉（比如没有变量引用它），它捕获的变量也会被回收。实际项目中容易忽略这点：
- 把限流器闭包存在 map 里但忘了清理，会导致内存泄漏（尤其带时间戳切片的滑动窗口实现）
- HTTP handler 中返回的闭包如果被中间件链长期持有，而 handler 已经结束，状态却还在，可能和预期不符
- 闭包里存了大对象（如
map[string]*big.Struct），又没做清理，GC 压力会上升
真正麻烦的不是“状态消失”，而是“状态残留”——尤其是带时间戳数组的滑动窗口限流器，若不主动清理过期项，slice 会不断增长，最终拖慢每次检查。
