闭包捕获变量时获取的是内存地址，导致变量逃逸至堆上且生命周期延长；验证需用go build -gcflags="-m -l"查看“escapes”提示。
闭包捕获的变量不会在函数返回时释放，只要闭包值还可达，它引用的变量就一直活在堆上——这不是 bug，是 Go 编译器逃逸分析的必然结果。
闭包捕获的是地址，不是值
Go 闭包对外部变量做的是引用捕获，拿到的是变量内存地址。多个闭包共享同一地址，后续修改会影响所有闭包行为。
-
for i := 0; i < 3; i++ { defer func() { println(i) }() }→ 全部输出3，因为所有defer读的都是同一个i的最终值 - 修复方式只有两种：显式绑定新变量（
i := i）或参数传值（defer func(v int) { println(v) }(i)） - 结构体字段被闭包捕获时，整个结构体可能逃逸，哪怕只用了
s.Name字段
变量什么时候逃逸到堆上
逃逸不是由“用了闭包”决定的，而是由“变量生命周期是否超出当前栈帧”触发的。编译器静态判断，不依赖运行时。
- 闭包作为返回值：
func() func() int { x := 42; return func() int { return x } }→x必然escapes to heap - 闭包传给
go启动：go func() { _ = x }()→x极大概率逃逸 - 仅在函数内立即调用闭包，也可能逃逸（尤其 go1.21+），取决于内联和分析精度
-
&x显式取地址 →x强制逃逸，哪怕只是int
怎么验证逃逸是否发生
不能靠猜，必须看编译器输出。加 -l 禁用内联，才能准确定位逃逸源头。
立即学习“go语言免费学习笔记（深入）”；
- 命令：
go build -gcflags="-m -l" main.go - 关键线索：
moved to heap: x或x escapes to heap - 过滤更准：
go build -gcflags="-m -l" main.go 2>&1 | grep "escapes" - 注意：
fmt.Println(x)这类调用本身就会触发接口装箱逃逸，测试时优先用纯计算逻辑隔离变量
defer 闭包里捕获变量的特殊陷阱
defer 闭包执行时机晚于注册时机，但变量值读取发生在执行时——这个时间差是多数 bug 的根源。
- 命名返回值被
defer修改：func f() (x int) { x = 1; defer func() { x = 2 }(); return }→ 实际返回2，且x因被捕获而逃逸 -
defer func() { use(r.Body) }→ 整个*http.Request可能长期滞留，直到 handler 返回后很久才回收 - 即使
recover()拦截了 panic，逃逸已发生，无法撤回
最易被忽略的是：逃逸本身不报错，也不 crash，只表现为内存缓慢上涨、GC pause 增长、P99 延迟毛刺变多——问题藏在 profile 里，却不在日志中。
