为什么返回局部变量指针在 Go 里不会崩溃
Go 允许函数安全返回局部变量的指针，比如 func newPerson() *Person { p := Person{"Alice", 30}; return &p } —— 这在 C/c++ 中是未定义行为，但在 Go 中完全合法。原因不是“语言允许”，而是编译器在编译期就通过逃逸分析判定：只要 p 的地址被返回，它就必须活过函数结束，因此自动将 p 分配到堆上，而非栈上。
- 逃逸分析不看语法（比如有没有写
&），而看语义：变量是否“逃出作用域” - 即使你写的是值类型初始化
Person{...}，只要它的地址被传出（返回、赋给全局变量、传入 goroutine 等），它就逃逸到堆 - 反例：如果只是
fmt.Println(p)或process(p)（process接收值类型参数），p通常留在栈上
怎么知道某个变量到底逃没逃
用 go build -gcflags="-m -l" 查看逃逸分析结果。加 -l 是禁用内联，让分析更准确；多次运行可避免因内联优化掩盖真实逃逸路径。
- 关键输出示例：
moved to heap: p→ 变量p逃逸到堆 -
p does not escape→ 安全留在栈上 - 接口赋值常导致隐式逃逸：比如
var i Interface{} = p，哪怕p很小，也会触发逃逸（因接口底层需动态分配） - 闭包捕获局部变量也逃逸：
func() { return p.Name }若该闭包被返回，p就逃逸
go run -gcflags="-m -l" main.go # command-line-arguments ./main.go:12:14: &p escapes to heap ./main.go:12:14: from &p (address-of) at ./main.go:12:14 ./main.go:12:14: moved to heap: p指针 vs 值类型：选谁不该只看“大小”
结构体小于 16 字节？很多人凭经验说“用值类型”。但这只是启发式规则，不是铁律。真正起决定作用的是：它会不会逃逸，以及你是否需要修改原值或满足接口/方法接收者一致性。
- 小结构体也可能逃逸：比如作为
interface{}参数传入、被闭包引用、或方法接收者是值类型但该方法被接口调用 - 大结构体用指针未必省事：如果指针指向的对象本身因其他原因已逃逸，那“避免拷贝”的收益就被 GC 开销抵消了
- 方法接收者要统一：若已有方法用指针接收者（如
func (p *Person) SetName(...)），再用值类型初始化就会导致无法调用该方法 - 导出构造函数习惯用指针：如
NewPerson()返回*Person，这是约定，也天然规避了大结构体拷贝和接收者不一致问题
常见踩坑：以为“不用 & 就一定不逃逸”
这是最典型的误解。逃逸与否和你写不写 & 没有直接关系，只和变量是否被外部引用有关。一个看似“纯值传递”的场景，可能暗藏逃逸。
立即学习“go语言免费学习笔记（深入）”；
- 错误认知：
v := Vertex{1, 2}; return v→ 不逃逸；v := Vertex{1, 2}; return &v→ 逃逸 - 现实反例：
func f() interface{} { v := Vertex{1,2}; return v }→v仍会逃逸！因为interface{}需要堆上内存存放值和类型信息 - 另一个坑：
for i := range s { fmt.printf("%p", &s[i]) }→ 即使s是切片，&s[i]在循环中每次取地址，若该地址被存储或返回，整个底层数组可能被迫逃逸 - 优化方向不是“消灭所有指针”，而是减少不必要的接口包装、避免过早泛化、用具体类型替代
interface{}（尤其在 hot path）
逃逸分析是 Go 编译器替你做的隐形决策，但它不会替你权衡语义正确性。最危险的不是变量逃逸了，而是你没意识到它逃逸了，还误以为“栈上操作=快+安全”，结果在压测时发现 GC 频繁或内存占用异常高。