go 编译器会通过逃逸分析自动将可能被外部引用的栈变量提升至堆上分配，因此传递栈变量地址不会产生悬垂指针，程序行为始终安全且符合预期。
在 Go 中，开发者常误以为“局部变量一定分配在栈上，取其地址后若超出作用域就会导致悬垂指针”，但这段代码的实际运行结果（稳定输出 4 且无崩溃）恰恰揭示了 Go 运行时的关键设计特性：逃逸分析（Escape Analysis）。
当编译器检测到某个局部变量的地址被逃逸出当前函数作用域（例如：作为参数传入 goroutine、返回为函数返回值、赋值给全局变量等），它会自动将该变量从栈分配改为堆分配。这意味着 v1 虽然在 alloc_on_stack() 中声明为局部变量，但由于 &v1 被传入 go another_thread(vx)，编译器判定 v1 “逃逸”了，于是将其分配在堆上——整个生命周期由垃圾收集器管理，而非依赖函数栈帧的进出。
你可以通过 go build -gcflags="-m" 验证这一行为：
$ go build -gcflags="-m" main.go # 输出中会包含类似： # ./main.go:32:2: &v1 escapes to heap # ./main.go:26:15: vx escapes to heap
这明确表明 v1 已被提升至堆。因此 another_thread 中对 vx.a = 4 的写入是完全合法、线程安全（在无其他并发写入前提下）且无副作用的。
这种机制也是 Go 中惯用模式的基础，例如：
func NewUser(name string, age int) *User {
return &User{Name: name, Age: age} // ✅ 安全：编译器自动逃逸到堆
}
type User struct { Name string; Age int }⚠️ 注意事项：
- 不必手动管理“栈 vs 堆”，Go 编译器全自动决策；
- 逃逸会带来轻微堆分配开销和 GC 压力，高频短生命周期对象可借助 sync.Pool 优化；
- 若需强制避免逃逸（极少数性能敏感场景），应避免返回局部变量地址、不传入 goroutine、不赋值给接口或映射等；可通过 -gcflags="-m -m" 深度分析逃逸路径。
总之，Go 的内存安全性不仅依赖 GC，更始于编译期的静态逃逸分析——它让开发者既能享受指针的灵活性，又无需承担 C/C++ 式的悬垂指针风险。
