defer闭包读取的是执行时变量的当前值，属引用捕获而非快照；常见错误如for循环中defer引用同一变量i，最终全部输出循环结束后的i值。
defer 闭包里读的到底是哪个时刻的变量值
它读的是 defer 真正执行时那个变量的当前值，不是注册 defer 语句那一刻的值。这和“快照”完全相反，是典型的引用捕获。
常见错误现象：for i := 0; i → 输出全是 <code>3。
原因：所有 defer 共享同一个循环变量 i 的内存地址；等函数返回前统一执行时，i 已经是终值 3。
关键点：Go 不会为每次 defer 自动创建新绑定，除非你显式干预。
立即学习“go语言免费学习笔记（深入）”；
怎么让 defer 拿到循环中的正确值
两种可靠写法，本质都是切断对原变量的共享引用：
-
i := i在循环体内做短变量声明，创建独立绑定：for i := 0; i < 3; i++ { i := i defer fmt.Println(i) } - 用参数传值，让求值发生在注册时：
for i := 0; i < 3; i++ { defer func(val int) { fmt.Println(val) }(i) }
不推荐写法：defer func() { fmt.Println(i) }()（末尾带括号）——这是立即执行，不是延迟；defer (func() { ... })() 同理无效。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
命名返回值被 defer 修改时的可见性
如果函数声明了命名返回值（如 func foo() (err error)），defer 中的闭包可以直接读写这个变量，且修改会影响最终返回值。
典型陷阱：
func bad() (x int) {
x = 1
defer func() { x = 2 }()
return // 实际返回 2，不是 1
}
问题在于逻辑隐蔽：return 语句本身不显式赋值，但命名返回值变量 x 在栈帧中持续存在，defer 修改的就是它。
安全做法：避免在 defer 中修改命名返回值；如需善后，改用普通局部变量 + 显式 return。
闭包捕获大对象导致 GC 延迟
只要闭包还活着，它捕获的变量就不会被 GC 回收——哪怕外层函数早已返回。编译器会自动把该变量从栈逃逸到堆。
风险场景：
- 闭包注册为 HTTP handler：
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { /* 用了 r.Body */ })→r整个结构体可能长期驻留 - 闭包存入全局 map 或启动 goroutine 后未释放
排查方法：用 go tool compile -m 看逃逸分析，确认哪些变量被抬升到堆；清理手段是缩小闭包捕获范围，比如只传需要的字段而非整个 struct。
最易被忽略的一点：这种内存滞留没有 panic、没有报错，只表现为服务运行越久内存越高，且 profile 里找不到明显泄漏点。
