go闭包捕获变量地址而非值，循环中所有闭包共享同一变量i的地址，故均输出最终值；这是设计特性，非bug。
Go 闭包捕获的是变量的内存地址，不是值快照；所有共享该变量的闭包读到的都是最新值——这不是 bug，是设计使然。
for 循环中闭包全输出最后一个值？因为 i 只有一份地址
常见错误现象：for i := 0; i 输出全是 <code>3。
根本原因：Go 不为每次循环迭代创建新变量，i 在整个 for 块中只分配一次内存地址，所有闭包都持有它。
- 修复方式一：在循环体内用短变量声明切断引用 ——
i := i创建新绑定 - 修复方式二：把
i当作参数传入闭包 ——go func(x int) { fmt.Print(x) }(i) - range 遍历同理：
v是复用的，不能直接在闭包里用；要用v := v或传参
defer 中闭包读的是执行时刻的变量值，不是注册时刻
例如：defer func() { fmt.Println(i) }() 注册时不读 i，真正执行时才读 —— 所以它看到的是函数返回前那一刻的 i 值。
混合写法陷阱：defer func(x int) { fmt.Println(x, i) }(i) —— x 是注册时值，i 是执行时值。
命名返回值会被 defer 修改：func foo() (x int) { x = 1; defer func() { x = 2 }(); return } 实际返回 2。
闭包延长变量生命周期，但不会自动拷贝大对象
只要闭包还被引用，它捕获的变量就不会被 GC 回收——哪怕外层函数早已返回。
- 结构体、切片被闭包捕获时，整个对象不会被拷贝；闭包持有的是原变量的地址
- 典型风险场景：
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { use(r.Body) })→ 整个*http.Request可能长期驻留 - 安全做法：缩小捕获范围，比如只传
r.URL.Path而非整个r；避免捕获大struct、大slice - 排查方法：
go tool compile -m查看逃逸分析，确认哪些变量被抬升到堆
最易被忽略的一点：这种内存滞留没有 panic、没有报错，只表现为服务运行越久内存越高，且 pprof 里找不到明显泄漏点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
