约 11 分钟4 张卡

Go 逃逸分析

逃逸分析是编译器沿引用和赋值关系，判断对象能否安全放在栈上的分析。对象的引用如果可能比当前栈上的存储活得更久，就需要安排足够长的生命周期。Go 允许返回局部变量的指针，正是因为存储位置不会仅由源码中的声明位置决定。

面试中判断是否逃逸，要看对象交给了谁、调用方还能保留多久，以及编译器掌握了多少信息。看到 &、接口或闭包就直接判定堆分配，会漏掉内联和数据流分析的作用。本文使用 Go 1.22.12；栈、堆和分配器的职责见 Go 内存分配。

1. 面试核心

先记住这几条，再读正文

逃逸分析发生在编译期，负责保护对象的生命周期。它需要避免堆对象留下不安全的栈指针，也要避免一个引用继续使用已经结束或被复用的栈存储。卡 · 生命周期与数据流
返回局部变量指针是安全的，但不能仅凭这个写法断定每次调用都发生堆分配。内联可能把函数体纳入调用方，让编译器看到这个对象没有继续向外流出。卡 · 返回指针与内联
参数流向返回值，不等于参数指向的对象已经逃逸到堆。要结合调用方怎么使用结果，区分 leaking param ... to result、moved to heap 和实际分配次数。卡 · 编译器报告
编译器信息不足、对象过大或切片空间无法静态确定，也会影响栈分配。接口调用和闭包是需要检查的场景，不是可以脱离上下文使用的判定口诀。卡 · 生命周期与数据流
堆分配会带来分配、保留和 GC 成本，但逃逸本身不是内存泄漏或程序错误。先找真实的分配热点，再保持语义不变地优化，并用分配统计与业务指标验证。卡 · 分配优化

2. 生命周期与数据流

卡 · Go 逃逸分析做什么，哪些条件会影响结果？

2.1 编译器要保证什么

一个函数的栈帧不会永久保留。函数返回后，对应空间可以用于其他调用；循环中的存储也可能被后续迭代复用。编译器必须保证一个仍然有效的 Go 引用，不会指向已经结束其生命周期的旧对象存储。

Go 1.22.12 的逃逸分析把变量、隐式创建的对象和赋值关系组织成数据流图，检查地址可能流向哪里。除了当前函数，它还记录参数向堆、向返回值流动的信息，供能够确定目标的调用位置使用。

因此，判断时应沿着具体路径看：局部对象的地址只是交给一个临时读取它的函数，还是存入了全局变量、可能在调用结束后继续存在的对象，或者被返回给调用方？这些路径有不同的生命周期要求。

编译器分析也有精度边界。它不会执行程序来证明某次运行的所有分支，而会在无法排除较长生命周期时采取保守处理。源码中“我知道这里不会保存它”，并不等于编译器已经得到这份信息。

2.2 编译期决策与运行时存储

编译期判断需要堆存储后，生成的代码会按相应路径创建对象。一般不是程序先把对象放在栈上，等函数准备返回时再临时把它搬到堆上。

这与 goroutine 栈增长时复制栈内容是两件事，也与 GC 判断堆对象是否仍可达是两件事。逃逸分析决定如何满足存储生命周期，GC 处理堆对象后续的回收，见 Go 垃圾回收。

“没有逃逸”也不能直接翻译成“必定占用了几个栈字节”。后续优化可能把值放在寄存器中、只保留其中的字段，或者消除不需要的对象。

3. 返回指针与内联

卡 · 返回局部变量的指针安全吗？一定会有一次堆分配吗？

内联是把被调用函数的代码展开到调用位置的编译优化。它能改变编译器看到的分析范围，使原本跨函数边界的引用流动变成同一段代码里的局部使用。

下面两个函数都返回局部变量的地址，其中一个允许正常内联，另一个用 //go:noinline 固定函数边界：

package main

import (
	"fmt"
	"testing"
)

var result int

func square(n int) *int {
	x := n * n
	return &x
}

//go:noinline
func squareSeparate(n int) *int {
	x := n * n
	return &x
}

func main() {
	a := testing.AllocsPerRun(1000, func() { result = *square(7) })
	b := testing.AllocsPerRun(1000, func() { result = *squareSeparate(7) })
	fmt.Println(a, b, result)
}

在 Go 1.22.12、darwin/arm64、默认优化下，输出为 0 1 49。内联后的 square(7) 只在当前调用方读取结果，不需要把这个整数作为独立堆对象保留下来。squareSeparate 保留函数边界，返回的指针需要引用函数返回后仍有效的存储，观察到一次堆分配。

两种写法都安全。差异在于生成代码是否需要堆对象，不在于其中一个会产生悬空指针。//go:noinline 只是用于对照分析条件，不是推荐给业务代码的性能开关。

如果对整个示例使用 go run -gcflags=-l main.go 关闭内联，这个版本下输出会变为 1 1 49。因此，不能用关闭内联后的结果代表默认构建，也不能把某次得到的零次分配当作语言保证。

4. 编译器报告

卡 · leaking param to result 和 moved to heap 有什么区别？

4.1 查看分析结果

在独立目录保存示例为 main.go 后，使用 go build -gcflags=-m=2 main.go 可以查看较详细的优化和逃逸报告。-m 输出优化判断，多次指定或使用 -m=2 会提供更多信息；-l 则是关闭内联，只有需要对照时再加。

报告描述的是编译器看到的表达式和流向，不能仅搜索一个 escapes 就给整个函数下结论：

报告片段	主要含义	仍需检查什么
`moved to heap: x`	这个分析位置的 `x` 需要堆存储	是否另有内联后的调用位置；最终执行了哪条路径
`new(T) escapes to heap`	这个创建表达式被判为需要堆分配	运行时是否确实执行、对象是否为零大小等条件
`does not escape`	该表达式未被分析为向外逃逸	后续优化和实际代码生成，不能据此断言固定栈布局
`leaking param: p to result ~r0 level=0`	参数指针本身流到返回值	调用方是否继续保存返回的指针
`leaking param content`	参数指向的内容通过相应路径向外流动	具体间接引用关系，不能直接说参数变量自身被搬到堆

前面的 square 原函数可能出现 x 需要堆存储的报告，但内联到具体调用位置后，编译器还能重新处理那个局部实例。报告中可能同时出现原函数和内联位置的信息，这并不与实际观察到零次分配矛盾。

4.2 参数流向返回值

把传入的指针原样返回，不会自动让调用方的对象进入堆。下面保留函数边界，分别比较返回参数和保存参数：

package main

import (
	"fmt"
	"testing"
)

var saved *int
var result int

//go:noinline
func identity(p *int) *int { return p }

//go:noinline
func save(p *int) { saved = p }

func main() {
	a := testing.AllocsPerRun(1000, func() {
		x := 7
		result = *identity(&x)
	})
	b := testing.AllocsPerRun(1000, func() {
		x := 7
		save(&x)
	})
	fmt.Println(a, b, result, *saved)
}

输出为 0 1 7 7。identity 的参数流向返回值，但调用方只是立即解引用读取 x，没有继续保存指针。save 把指针交给全局变量 saved，x 需要在本次调用结束后仍有效。

对应报告中，identity 会说明 p 流向返回值；save 的参数则流向堆。关注的是 p 指向的对象需要活多久，不是“函数有一个指针参数，所以参数变量一定在堆上”。

fmt.Println 自己也可能让用于输出的接口参数出现在报告里。本例把输出放在 AllocsPerRun 测量之后，避免把打印的分配混进待比较的代码。报告里的某个值向接口流动，也不表示整个被访问的对象都以同一种方式逃逸。

5. 影响判断的其他条件

卡 · Go 逃逸分析做什么，哪些条件会影响结果？

5.1 接口调用与目标信息

接口类型本身不是逃逸开关。编译器能确定具体调用目标时，可以利用被调用函数的信息；如果只能看到一个可能有不同实现的接口调用，就可能需要保守地认为参数会被保存。

package main

import (
	"fmt"
	"testing"
)

type Reader interface{ Read([]byte) }
type Fill struct{}

func (Fill) Read(b []byte) { b[0] = 7 }

var result byte

//go:noinline
func known() byte {
	var b [8]byte
	Fill{}.Read(b[:])
	return b[0]
}

//go:noinline
func throughInterface(r Reader) byte {
	var b [8]byte
	r.Read(b[:])
	return b[0]
}

func main() {
	a := testing.AllocsPerRun(1000, func() { result = known() })
	b := testing.AllocsPerRun(1000, func() { result = throughInterface(Fill{}) })
	fmt.Println(a, b, result)
}

Go 1.22.12 下输出为 0 1 7。known 中，编译器看得到 Fill.Read 不保留切片；throughInterface 保留了接口调用边界，不能在它的函数体里假定所有 Reader 都与 Fill 一样，因此把局部数组 b 按需要更长生命周期处理。

这不证明接口调用永远分配，也不证明接口转换本身在此分配了一份 8 字节数组。原因是参数所指的数组通过无法静态确定目标的调用流出；内联、去虚拟化或代码组织变化后，需要重新检查。接口的类型关系见 Go 接口。

5.2 大小与动态空间

即使引用没有离开当前函数，编译器也不会无条件把任意大小的对象塞进栈。Go 1.22.12 默认实现对显式变量有 10 MiB 的大小限制，对 new、切片底层数组等隐式对象有 64 KiB 的限制，还会检查对齐条件。这些是实现策略，不能作为未来版本的语言承诺。

例如，常量大小且满足其他条件的 make([]byte, 16) 可以不在堆上分配。若分析时只能看到 make([]byte, n)，无法把 n 化成合适的编译期常量，会报告 non-constant size，采用堆分配路径。即使运行时传入的恰好是 16，也不等于编译时已经知道这个值。

大小检查的 too large for stack 和引用流出是不同原因。阅读报告时先确认具体原因，不能把所有堆分配都解释成“函数返回了它”。运行时执行零长度或零大小创建等特殊情况时，也不能仅凭编译期选择的路径推断一定发生非零空间分配。