闭包捕获变量易致内存泄漏：goroutine 持有长生命周期对象引用、循环变量共享、defer 闭包拖住资源、http 响应体关闭后仍持有 resp、time.AfterFunc/Ticker 闭包失控。应显式传参、传值替代指针、及时 stop ticker、避免闭包隐式引用。
闭包捕获变量时，别让 goroutine 持有长生命周期对象的引用
Go 中最常见的内存泄漏场景之一：goroutine 在闭包中捕获了本不该长期存活的变量（比如大 slice、map、结构体指针），而该 goroutine 又迟迟不退出。此时即使外部作用域早已结束，这些变量仍被闭包隐式引用，无法被 GC 回收。
- 避免在
go func() { ... }()闭包中直接使用外层循环变量，如for i := range items { go func() { use(i) }() }—— 所有 goroutine 共享同一个i地址，最终可能全用最后一次值，且延长i生命周期 - 正确写法是显式传参：
for i := range items { go func(idx int) { use(idx) }(i) }，或用局部变量绑定：for i := range items { idx := i; go func() { use(idx) }() } - 若闭包需访问结构体字段，优先传值或只传必要字段，而非整个结构体指针；尤其警惕
*http.Request、*sql.DB等重型对象被无意捕获
defer + 闭包组合容易导致 context 或连接泄漏
闭包常用于 defer 清理资源，但若闭包内引用了本应短命的上下文或连接句柄，而 defer 延迟到函数返回后才执行，就可能拖住资源释放时机。
-
defer func() { conn.Close() }()看似合理，但如果conn是从context.WithTimeout创建的，而闭包又间接持有该ctx（例如通过日志、错误包装等），可能导致 ctx 被延长，进而延迟超时判定和底层连接释放 - 更安全的做法是：清理逻辑尽量不依赖闭包捕获，改用显式参数传递，例如
defer closeConn(conn)，其中closeConn是普通函数 - 对
http.Client发起的请求，别在 defer 闭包里调用resp.Body.Close()后还继续读取resp字段——Body 关闭后resp部分字段（如resp.Header）仍可访问，但若闭包意外持有整个resp，可能拖住底层 TCP 连接池中的连接
定时器和 ticker 的闭包引用必须可控
time.AfterFunc 和 time.NewTicker 创建的闭包，生命周期由时间系统管理，一旦启动就难以主动中断，极易因闭包捕获导致泄漏。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 永远不要在
time.AfterFunc闭包中捕获大对象或上下文；若需传递数据，只传必要字段，且确保这些字段本身不携带隐藏引用链（如 struct 中嵌套的sync.Mutex或context.Context） - 使用
time.Ticker时，务必配对调用ticker.Stop()；若在闭包中启动 ticker 但没暴露 stop 接口，外部无法控制其生命周期，ticker 会持续运行并保持所有捕获变量存活 - 注意
time.After返回的 channel 本身不泄漏，但若你在 select 分支中用闭包处理它（如case ），要确认 <code>heavyWork不反向引用触发它的 timer 或周边变量
测试时用 runtime.GC() 和 debug.ReadGCStats 验证闭包泄漏
光靠代码审查难发现闭包泄漏，得靠运行时观测。关键不是看内存绝对值，而是看重复操作后对象数量是否持续增长。
立即学习“go语言免费学习笔记（深入）”；
- 在单元测试中模拟高频闭包创建场景（如启停 1000 次 goroutine），然后调用
runtime.GC()，再用debug.ReadGCStats检查NumGC和PauseTotalNs是否异常升高，或用runtime.ReadMemStats对比Alloc/HeapObjects增量 - pprof 是更直接手段：启动
net/http/pprof，跑完测试后访问/debug/pprof/heap?gc=1，用go tool pprof查看 top alloc_objects，重点排查匿名函数（如func·001）关联的堆分配路径 - 一个易忽略点：编译器有时会把闭包“逃逸”到堆上，即使它看起来只用栈变量——可通过
go build -gcflags="-m" main.go观察 “moved to heap” 提示，确认哪些闭包实际产生了堆分配
