go闭包捕获变量会导致内存泄漏，因闭包持有变量引用阻碍gc；正确做法是在循环体内用i := i显式创建独立副本，确保每个闭包绑定专属值。
闭包隐式捕获变量会导致该变量无法被 GC 回收，只要闭包本身还存活——哪怕它只被存进一个全局 map 或 channel，或作为 goroutine 的启动参数，都会让整个捕获链上的对象长期驻留堆中。
循环中直接捕获循环变量 i 导致所有闭包共享同一地址
这是最典型、也最容易忽略的泄漏源头。Go 中 for 循环变量 i 是复用的，每次迭代不新建变量，而是修改其值；匿名函数若直接引用 i，所有闭包实际都指向同一个堆地址。
- 现象：返回的闭包列表调用时全输出最终值（如全是
10），且i所在栈帧无法回收，连带它引用的其他大对象也被钉住 - 修复方式不是“加
break”或“改用range”，而是显式创建局部副本：i := i必须放在循环体内，且在闭包定义前 - 注意：
go func(i int) { ... }(i)也有效，但仅限于立即启动 goroutine；若闭包要存起来延后执行，仍需i := i方式
defer 中闭包捕获 req.Body 或大 []byte 引发延迟释放
defer 不是“安全垫”，它是函数返回前才执行的钩子。若 defer 的闭包捕获了入参或局部大对象（如 HTTP handler 中的 req.Body、解析后的 bigData），这些对象会一直活到函数退出——而 handler 可能已返回响应，用户早已断开连接。
- pprof 常见线索：
inuse_space持续上涨，但allocs平稳；调用栈里频繁出现runtime.deferproc+http.HandlerFunc.ServeHTTP - 错误写法：
defer func() { log.Printf("body: %v", req.Body) }()——req.Body被隐式捕获，整块底层[]byte无法释放 - 正确写法：
defer func(body io.ReadCloser) { log.Printf("body len: %d", body) }(req.Body)，或更稳妥地先读取并转为小结构体再传入
全局注册表中存储闭包，且未提供注销机制
把闭包塞进 map[string]func() 或 sync.Map 看似无害，但一旦注册后永不清理，闭包所捕获的上下文（如数据库连接、配置结构体、甚至整个 *http.Request）就永久滞留内存。
- 典型场景：插件系统、事件总线、中间件链注册、自定义指标上报回调
- 风险点不在闭包本身，而在它捕获的“短命对象”——比如 handler 里捕获了
ctx和user，注册进全局eventHandlers，后续无人调用Unregister - 必须配套设计注销接口，并在资源生命周期结束时显式调用；避免用
unsafe或反射绕过引用计数
goroutine 启动时闭包捕获 req 且未监听 ctx.Done()
在 HTTP handler 内起 goroutine 做异步日志或清理，若闭包直接引用 req 或 resp，又没绑定请求上下文，就会生成“孤儿 goroutine”——它可能比请求存活时间长十倍，持续持有 buffer、header map、TLS 连接等。
- pprof 查
goroutine：大量状态为chan receive或select，数量随 QPS 线性增长 - 错误模式：
go func() { log.Println(req.URL.Path) }()—— 没 context 控制，没超时，没 recover - 正确模式：
go func(ctx context.Context, url string) { select { case
真正棘手的不是闭包语法本身，而是它让变量逃逸路径变得不可见——你删掉一行 i := i，泄漏就发生；你漏掉一次 Unregister，服务跑三天后 RSS 突然翻倍。排查时优先盯死三处：全局容器、defer 语句块、以及所有以 go func() 开头的行。
