go闭包捕获变量地址而非值快照，所有闭包共享同一变量内存地址，读取的是当前最新值；for循环中i只有一份地址，导致闭包执行时均输出终值。
闭包捕获的是变量地址，不是值快照
Go 闭包不保存变量当时的值，而是直接持有变量的内存地址。这意味着所有共享同一变量的闭包，读到的永远是该变量当前最新值——哪怕外层函数早已返回。
-
i、name、config在闭包里都不是副本，而是指向原始栈/堆位置的指针 - 基本类型（如
int、string）看似“值语义”，但闭包绑定的仍是变量本身；赋值操作是复制，但闭包没参与那次复制 - 结构体或切片被闭包捕获时，整个对象不会拷贝；闭包持有的是原变量地址，改字段或追加元素会同步反映
- 典型翻车：多个 goroutine 共享循环变量
i，最终全打印3，因为它们都读同一个地址上最后存的值
for 循环中闭包总输出最后一个值？不是 bug，是设计如此
Go 不为每次迭代创建新变量，i 在整个 for 块中只有一份内存地址。所有闭包注册时都绑定了这个地址，执行时自然看到终值。
- 错误写法：
for i := 0; i → 全输出 <code>3 - 正确做法一：
for i := 0; i —— 短变量声明创建独立绑定 - 正确做法二：
for i := 0; i —— 参数传值，在启动 goroutine 时求值 -
range遍历同理：v是复用的，不能直接在闭包里用；必须写成v := v或传参
defer 中闭包读的是执行时刻的变量值
defer 注册时不读变量，真正执行时才读——所以它看到的是函数返回前那一刻的值，不是注册那刻的快照。
- 常见错误：
for i := 0; i → 全输出 <code>3 - 修复方式同上：用
i := i或func(x int) { ... }(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，因为x是栈帧中持续存在的变量
闭包延长变量生命周期，容易拖住大对象
只要闭包还被引用，它捕获的变量就不会被 GC 回收——哪怕外层函数早就返回了。编译器会自动把该变量从栈逃逸到堆。
- 高风险场景：
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { use(r.Body) })→ 整个*http.Request可能长期驻留 - 排查方法：
go tool compile -m查看逃逸分析，确认哪些变量被抬升到堆 - 安全做法：缩小闭包捕获范围，比如只传
r.URL.Path而非整个r；避免捕获大 struct、大 slice - 最易被忽略的一点：这种内存滞留没有 panic、没有报错，只表现为服务运行越久内存越高，且
pprof里找不到明显泄漏点
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
