闭包捕获局部变量指针必然导致逃逸，因编译器需确保返回后仍可寻址，故将变量分配到堆；更严重的是多个闭包共享同一地址引发数据竞争或终值误读。
闭包捕获局部变量指针几乎必然导致逃逸，且语义风险比逃逸本身更严重——它让多个闭包共享同一内存地址，造成数据竞争或终值误读。
闭包捕获 &i 为什么一定逃逸？
只要闭包体中出现 &i（或间接取址，如 &s.Name），Go 编译器就认定该变量必须在函数返回后仍可寻址。而栈帧届时已销毁，唯一安全做法是把 i 分配到堆上。
-
defer func() { println(&x) }()→x必然逃逸，哪怕x是int -
go func() { use(&s.Field) }()→ 整个结构体s逃逸（Go 不支持字段级逃逸分析） - 验证命令必须加
-l：运行go build -gcflags="-m -l" main.go，看到moved to heap: x即确认
for 循环里用 defer func() { use(i) }() 的双重问题
这不仅是逻辑错误（所有 defer 打印同一个终值），更是逃逸放大器：循环变量 i 被所有闭包共用地址，编译器只能把它整个抬到堆上。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
for i := 0; i → 输出 <code>3 3 3，且i逃逸 - 正确写法一：
defer func(val int) { fmt.Println(val) }(i)→val是副本，通常不逃逸 - 正确写法二：
i := i; defer func() { fmt.Println(i) }()→ 新绑定变量，编译器可优化其栈上生命周期 - 绝对避免：
defer func() { fmt.Println(i, &i) }()→&i拖累整个闭包，i和val都逃逸
闭包捕获指针时的并发与语义陷阱
逃逸只是表象，真正危险的是指针共享带来的非预期行为——闭包拿到的是地址，不是快照。多个 goroutine 或多次 defer 执行时，读到的可能是已被覆盖的值。
-
for _, v := range items { go func() { process(v) }() }→ 所有 goroutine 共享同一个v地址，最终都处理最后一个元素 - 修复不是“加
sync.Mutex”，而是切断地址复用：v := v; go func() { process(v) }() - 若
v是结构体指针（如*User），即使只读v.Name，也需注意底层数据是否被其他 goroutine 修改 - 闭包捕获全局变量（如
config.DB）同理：任何地方改了config，所有已注册闭包立刻感知，测试难隔离、线上难控制
最易被忽略的一点：逃逸分析结果依赖 -l（禁用内联）。没加这个参数，escapes to heap 提示可能出现在调用方而非定义行，误判率极高。而一旦逃逸发生，无论 defer 是否最终执行、goroutine 是否启动，堆分配已不可逆。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
