闭包捕获的变量不会随外层函数返回而消失，Go GC依据引用关系而非作用域回收内存，只要闭包存活，其捕获变量就持续驻留堆中，易引发内存泄漏。
闭包捕获的变量不会随外层函数返回而消失
Go 的 GC 不按“函数作用域”回收，而是看变量是否还被任何存活对象引用。闭包一旦捕获了某个变量（比如 i、r.Body 或一个大结构体），只要这个闭包本身还被持有（例如存进全局 map、注册为 HTTP handler、启动 goroutine 后未退出），它捕获的变量就无法被回收——哪怕外层函数早已执行完毕。
常见现象是服务运行越久内存越高，pprof 查不到明显泄漏点，go tool compile -m 却显示大量变量“moved to heap”。这不是 bug，是闭包语义的自然结果。
- HTTP handler 里直接用
r全量：整个*http.Request可能长期驻留 - 循环中把闭包塞进切片或 map 且未清空：所有被捕获的循环变量都滞留
- goroutine 中启动闭包并忘记 stop 信号：闭包 + 捕获变量一起卡在堆上
defer 里的闭包会让变量逃逸到堆
当 defer 绑定一个闭包（如 defer func() { log.Println(x) }()），编译器会强制把 x 从栈逃逸到堆——因为 defer 的执行时机晚于函数返回，栈帧已销毁，必须保证 x 地址仍有效。
这本身没问题，但若 x 是大对象（比如 1MB 的 struct 或含指针的 slice），每次 defer 都会触发一次堆分配，频繁调用下 GC 压力陡增。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免在 hot path（如高频请求处理函数）里 defer 大对象闭包
- 改用显式传值：比如
defer func(val int) { ... }(x)，让求值发生在 defer 注册时，减少闭包捕获范围 - 对命名返回值要特别小心：
defer func() { err = fmt.Errorf(...) }()会延长err生命周期，且修改直接影响返回值
如何验证闭包是否导致意外逃逸
最直接的办法是加编译标志看逃逸分析：go build -gcflags="-m -l" main.go。重点关注输出里带 ... moved to heap 的行，尤其注意闭包参数和捕获字段。
如果发现本该栈分配的小变量（如 int、小 struct）也被抬升，大概率是闭包捕获了它所在的更大宿主对象（比如闭包捕获了 user struct，而只用了其中 user.ID，但整个 user 都得上堆）。
- 缩小捕获范围：改
func() { doSomething(user) }为func(id int) { doSomethingByID(id) }(user.ID) - 避免闭包持有接口类型（如
interface{}），它隐式携带底层值指针，容易延长生命周期 - 用
runtime.ReadMemStats对比前后堆对象数，确认是否因闭包注册导致对象堆积
goroutine + 闭包组合最容易漏掉清理
闭包本身不危险，危险的是它和 goroutine 结合后形成的“隐形引用链”。比如 go func() { use(data) }()，只要 goroutine 还在跑，data 就不会被回收——哪怕 use 已经执行完，goroutine 仍在等待 channel 或 sleep。
这种泄漏无声无息，GC 看起来正常，但内存持续上涨。线上排查时往往要结合 pprof/goroutine 看活跃 goroutine 数量，再顺藤摸瓜找谁持有了闭包。
- 给 goroutine 加超时或 context.Done() 监听，确保能退出
- 避免把闭包存进全局 map 后永不删除；真需要缓存，配 TTL 或弱引用（如
sync.Map+ 显式 delete） - 测试阶段用
GODEBUG=gctrace=1观察 GC 频次变化，突增往往意味着闭包/ goroutine 滞留
