go 编译器会自动进行逃逸分析，当检测到局部变量的地址被逃逸出当前函数作用域（如返回指针、传入 goroutine）时，会将其分配在堆上而非栈上，从而避免悬垂指针问题。
在 Go 中，开发者常误以为“局部变量一定在栈上”“取地址后仍留在栈上就必然危险”，但你的实验恰恰揭示了 Go 运行时的关键保障机制：逃逸分析（Escape Analysis）。
当你在 alloc_on_stack() 中声明 var v1 v 并对其取地址 &v1，随后将该指针传递给 update_v，再进一步传入 go another_thread(vx) —— 此时编译器已静态判定：v1 的生命周期必须延伸至 another_thread 执行完毕（即其指针被 goroutine 持有）。因此，v1 不会被分配在栈上，而是由编译器自动提升（promote）至堆上分配。
这解释了为何输出中所有 printf("%p") 显示相同地址（如 0x1043617c），且 another_thread 中对 vx.a = 4 的写入完全合法、无未定义行为——它操作的是堆内存中一个仍有效、受 GC 管理的对象，而非已销毁的栈帧。
你可以通过 go build -gcflags="-m" main.go 验证这一过程：
./main.go:25:10: &v1 escapes to heap ./main.go:33:17: vx escapes to heap
输出明确指出 v1 已逃逸至堆。
✅ 正确理解带来的实践意义：
- 返回局部变量地址是安全且推荐的惯用法，例如：
func NewConfig() *Config { return &Config{Timeout: 30, Retries: 3} // 完全合法、高效 } - 不必手动管理内存或规避指针传递；Go 的逃逸分析在编译期完成决策，运行时零开销。
- 唯一需关注的是性能影响：频繁逃逸可能增加 GC 压力。若确定变量生命周期严格限定于函数内，可尝试重构（如避免闭包捕获、减少指针传递）以抑制逃逸——但应以 profile 数据为依据，而非过早优化。
⚠️ 注意事项：
- 逃逸分析是编译期静态分析，无法覆盖所有动态场景（如反射、unsafe 操作），此时需开发者谨慎保证内存安全；
- defer、闭包、channel 发送等同样触发逃逸判断；
- 使用 go tool compile -S 可查看汇编中实际的内存分配指令（如 CALL runtime.newobject 表明堆分配）。
总之，Go 通过智能的逃逸分析，在保持 C/Cpp 级别内存效率的同时，消除了传统栈指针悬挂的风险——你所观察到的“安全行为”，正是语言设计者精心构建的安全抽象。
