defer func() { println(x) }() 不一定逃逸；若 x 是小基础类型且闭包未外泄（不返回、不传 goroutine、不赋全局），则 x 保留在栈上，不逃逸；逃逸取决于生命周期是否超出函数作用域。
defer 闭包捕获局部变量时，该变量是否逃逸，取决于它是否被取地址（&x）或是否被闭包实际通过指针方式访问——不是所有 defer 闭包都导致逃逸，但一旦出现 &x 或结构体字段地址被隐式获取，逃逸就几乎不可避免。
defer 闭包里写 func() { println(x) } 会逃逸吗？
不一定。如果 x 是基础类型（如 int、string），且闭包未被返回、未传入 goroutine、也未被赋给全局变量，编译器通常能证明它只在当前栈帧内使用，x 保留在栈上，不逃逸。
- 逃逸的触发点不是「用了 defer」，而是「变量生命周期超出函数作用域」：比如闭包被 return 出去、或传给了另一个 goroutine
- 但如果
x是一个大数组（如[1024]int），即使没取地址，也可能因栈空间保守估计而逃逸 - 用
go build -gcflags="-m" main.go 2>&1 | grep "x.*escapes"可验证，注意加-l禁用内联，否则结果失真
为什么 defer func() { println(&x) }() 一定逃逸？
因为 &x 显式取地址，意味着闭包必须持有 x 的内存地址；而 defer 函数可能在函数返回后才执行，此时原栈帧已销毁，编译器只能把 x 分配到堆上保证地址有效。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 哪怕
x是int，只要出现&x，就强制逃逸 - 对结构体字段取地址（如
&s.name）也会导致整个结构体s逃逸——Go 当前不支持字段级逃逸分析 - 如果只是
println(s.name)（值访问），且s小于几字节，可能不逃逸；但换成println(&s.name)，立刻全量逃逸
defer 中捕获循环变量时，&i 和 i 的逃逸差异极大
常见写法 for i := 0; i 不仅逻辑错误（所有 defer 打印同一个地址），而且 <code>i 必然逃逸到堆——因为闭包需要在其生命周期内持续访问 &i，而该地址在循环结束后仍需有效。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是显式传参：
defer func(v int) { fmt.Println(&v) }(i)→ 此时逃逸的是每个v的副本，而非原始i；但注意：&v仍会让每个v单独逃逸 - 若只需值，去掉取地址：
defer func(v int) { fmt.Println(v) }(i)→v通常不逃逸，且避免了循环变量共享问题 - 切忌混合写法：
defer func(v int) { fmt.Println(v, &i) }(i)——&i仍拖累整个闭包，i逃逸，v也大概率被连带逃逸
真正容易被忽略的是：逃逸本身不等于 bug，但它是性能信号——堆分配 + GC 压力 + 缓存不友好。尤其在高频 defer 场景（如中间件、日志、监控计时），一个无意的 &x 可能让小函数变成 GC 热点。别只盯着「会不会 panic」，要盯住 go build -gcflags="-m -l" 的输出里那行 ... moved to heap。
