Go闭包捕获变量的内存地址而非值快照，导致外层函数返回后变量仍被引用而无法GC；for循环中闭包共享同一变量地址，故全输出最后一个值。
Go 闭包捕获的是变量的**内存地址**，不是值快照。只要闭包还活着，它捕获的变量就不会被 GC 回收——哪怕外层函数早已返回。这不是 bug，但极易引发意料之外的内存滞留。
for 循环中闭包全输出最后一个值？不是并发问题，是引用共享
现象：for i := 0; i 启动的 goroutine 全部输出 <code>3。
原因：Go 的循环变量 i 在整个 for 块中只有一份内存地址，所有闭包都绑定到这个地址；循环结束时 i == 3，后续执行自然都读到 3。
- 这不是竞态，同步调用也复现：
for i := 0; i 同样输出 <code>3 3 3 -
range中的v同理：每次迭代复用同一变量，不能直接在闭包里用v - Go 1.22+ 对
range值做了复制优化，但显式for变量行为未变，不可依赖
如何让每次迭代的闭包拿到正确的值
只有两种可靠方式，本质都是切断对原变量的引用：
-
传参捕获（推荐）：
go func(val int) { fmt.Println(val) }(i)—— 求值发生在调用时刻，val是独立副本 -
循环内重声明：
for i := 0; i —— <code>i := i是变量遮蔽，为每次迭代分配新栈空间 - 错误写法：
defer func() { fmt.Println(i) }()或go func() { fmt.Println(i) }()—— 都共享外层i地址
defer 中闭包读的是执行时的值，不是注册时的快照
现象：for i := 0; i 函数返回前统一执行，全部输出 <code>3。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
关键点：defer 注册时不读变量，真正执行时才读 —— 它捕获的是引用，不是快照。
- 修复方式与普通闭包一致：
defer func(val int) { fmt.Print(val) }(i)或i := i; defer func() { fmt.Print(i) }() - 命名返回值更危险：
func foo() (x int) { x = 1; defer func() { x = 2 }(); return }实际返回2，因为x是栈帧中持续存在的变量，defer直接改它 - 避免在
defer中修改命名返回值；如需善后，改用普通局部变量 + 显式return
闭包延长变量生命周期的真实代价
只要闭包值还被引用，它捕获的变量就无法被 GC 回收。编译器会自动把该变量从栈逃逸到堆。
- 典型风险场景：
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { use(r.Body) })→ 整个*http.Request可能长期驻留 - 排查方法：
go tool compile -m查看逃逸分析，确认哪些变量被抬升到堆 - 安全做法：缩小捕获范围，比如只传
r.URL.Path而非整个r；避免捕获大 struct、未清理的资源句柄 - 最易被忽略的一点：这种内存滞留没有 panic、没有报错，只表现为服务运行越久内存越高，且
pprof里找不到明显泄漏点
user 结构体，其实早该释放了。 
