《Go 语言高级编程》6.1 逃逸分析决策表

6.1 逃逸分析决策表

Go 的自动内存管理有一个副作用：你写 x := T{} 时，编译器可能把它放在栈上，也可能放到堆上，而你完全看不出来。放栈上几乎免费，放堆上要付出分配 + GC 的代价。决定这件事的是逃逸分析——一个能开、能读、但不该依赖直觉的工具。

本节要回答：-gcflags=-m 的输出怎么读，什么写法会让变量逃逸到堆、什么写法不会，以及怎么改结构避免逃逸。结论是：逃逸与否由「这个值的地址会不会被传出去」决定；本机实测「返回指针」比「返回值」慢约 28 倍（9.39 ns vs 0.33 ns），且每次都多 32 字节堆分配。

边界说明：卷一 4.1 只提过 unsafe.Sizeof 与结构体内存对齐，讲的是「一个值占多少字节」；本节讲的是「这个值住在栈还是堆」，是另一个问题。

6.1.1 -gcflags=-m 怎么读

打开逃逸分析的开关是 -gcflags=-m（-m=2 输出更详细）：

$ GOTOOLCHAIN=go1.27.0 go build -gcflags='-m' .
$ GOTOOLCHAIN=go1.27.0 go build -gcflags='-m=2' .    # 更详细
$ GOTOOLCHAIN=go1.27.0 go build -gcflags='-m -l' .   # -l 禁用内联，输出更干净

输出里的关键词只有几个：

**一个关键干扰项是内联。**内联会改变逃逸结论（内联后编译器能看到更多上下文），所以读原始结论时要配 -l 禁掉内联，否则满屏的 inlining call to 会淹没真正的 escapes to heap。

另外注意作用范围：-gcflags 默认只作用于当前包。要看依赖包的逃逸结论，得写 -gcflags='all=-m'；但 all= 会把标准库也刷一遍，输出量巨大，通常只在定位特定第三方包时才用。

$ GOTOOLCHAIN=go1.27.0 go build -gcflags='all=-m -l' ./... 2>&1 | grep escapes | head

6.1.2 决策表：什么会逃逸

逃逸的唯一判据是**「这个值的地址会不会被传出生它的函数」**。按这个判据整理：

两个容易误判的点：

• 「按值传递」不逃逸，「返回指针」逃逸——差一个 & 就是栈与堆的区别。
• 接口值一旦逃出函数，装箱就会逃逸，哪怕装的是个小整数。这是 fmt.Println(x) 在热路径上贵的原因。

6.1.3 逃逸为什么要付两次钱

栈分配几乎是免费的：函数返回时整块栈帧一起回收，不需要任何簿记。堆分配则要付两次：

1. 分配本身：向内存分配器要一块内存，可能要加锁、可能触发扩容。
2. 回收：这块内存变成 GC 的工作量。对象越多、越碎，GC 的标记与清扫成本越高。

这正是 6.1.4 的基准里 mkPtr 每次多出「32 B / 1 alloc」的原因——那 32 字节不只是「多占了内存」，而是「每次调用都给 GC 塞了一份待回收垃圾」。在一个每秒百万次调用的热路径上，这会把 GC 从「偶尔跑一次」变成「一直在跑」。

用 5.1 节的视角看，这也解释了为什么 Go 的内存模型只谈同步、不谈栈堆：栈/堆是实现的优化，语义上不可见。但在性能上，它决定了一切。

6.1.4 实测：一份文件里的正反例

把上面的情形写进一个文件，跑 -gcflags='-m -l'（禁内联）：

func newPoint() *Point { p := Point{1, 2}; return &p }   // 返回地址
func sumLocal(p Point) int { q := p; return q.X + q.Y }  // 值复制
func boxed(p Point) Shape { return p }                   // 装箱接口
func makeAdder(base int) func(int) int { return func(d int) int { return base + d } }
func localBuf() int { var buf [4]int; ...; return buf[0] + buf[3] }
func passToFmt(p *Point) { fmt.Println(p) }

真实输出（节选关键行）：

./main.go:13:2: moved to heap: p
./main.go:25:9: p escapes to heap
./main.go:30:9: func literal escapes to heap
./main.go:43:16: leaking param: p
./main.go:44:13: ... argument does not escape

逐行对上：

注意 sumLocal 与 localBuf 没有出现在逃逸行里——它们完全留在栈上。这验证了决策表里「按值传递」「局部定长数组」两条。

6.1.5 实测：逃逸的性能代价

逃逸的代价是「每次调用一次堆分配 + 一次 GC 压力」。用基准量化（Apple M1 Pro，GOTOOLCHAIN=go1.27.0）：

func mkPtr(a int64) *Big { p := Big{A: a}; return &p }
func mkVal(a int64) Big   { return Big{A: a} }

BenchmarkReturnPtr-10    	 1000000	         9.386 ns/op	      32 B/op	       1 allocs/op
BenchmarkReturnVal-10    	 1000000	         0.3328 ns/op	       0 B/op	       0 allocs/op
BenchmarkBoxStruct-10    	 1000000	        11.52 ns/op	      32 B/op	       1 allocs/op
BenchmarkNoBox-10        	 1000000	         0.3311 ns/op	       0 B/op	       0 allocs/op

整理成对比：

逃逸的逃逸证据也在同一份输出里：

./bench_test.go:12:28: moved to heap: p
./bench_test.go:17:18: moved to heap: p
./bench_test.go:31:16: Big{...} escapes to heap

第 12 行的 p 是 mkPtr 的局部变量，第 31 行的 Big{...} 是装箱成 any 的字面量。而 mkVal 没有任何逃逸行。

6.1.6 怎么改结构避免逃逸

知道了判据，改法就有了方向——让值的地址不外传：

一个常见的反直觉点：「大结构体按值传参」不一定是坏事。如果函数体短、编译器能内联，按值传的结构体可能整块留在栈上，反而比传指针（指针参数常被标记 leaking param）更便宜。判断标准不是「大不大」，而是「地址会不会外传」——这正是决策表的判据。

6.1.7 用 -m=2 定位逃逸来源

-m 只告诉你「逃逸了」，-m=2 会告诉你「在哪个函数里逃逸、为什么」。对同一份代码：

$ GOTOOLCHAIN=go1.27.0 go build -gcflags='-m=2 -l' . 2>&1 | grep -E "escapes to heap|moved to heap"
./main.go:13:2: p escapes to heap in newPoint:
./main.go:13:2: moved to heap: p
./main.go:25:9: p escapes to heap in boxed:
./main.go:25:9: p escapes to heap
./main.go:30:9: func literal escapes to heap in makeAdder:
./main.go:30:9: func literal escapes to heap
./main.go:43:16: leaking param: p

读法：p escapes to heap in newPoint 里的 in newPoint 指明逃逸发生在哪个函数。当一个值经过多层调用链逃逸时，-m=2 能一路标出每一跳——这正是排查「为什么这里分配了」的入口。

配合 go test -benchmem 使用最有效：先看 allocs/op 不为 0，再用 -m=2 找到那一处，最后改结构、重跑基准验证。

6.1.8 两个配套工具：预分配与 sync.Pool

逃逸是「编译器决定放堆」，但有些堆分配是你自己要求的——最典型的是增长式 append。用基准看差距（Apple M1 Pro）：

func buildNoPrealloc(n int) []int { var s []int; for i := 0; i < n; i++ { s = append(s, i) }; return s }
func buildPrealloc(n int) []int   { s := make([]int, 0, n); for i := 0; i < n; i++ { s = append(s, i) }; return s }

BenchmarkNoPrealloc-10    	  200000	      3762 ns/op	   25208 B/op	      12 allocs/op
BenchmarkPrealloc-10      	  200000	       635.0 ns/op	       0 B/op	       0 allocs/op

预分配把 12 次分配压到 0，快了约 5.9 倍——append 的几何扩容每次都复制旧内容，容量给足就只剩一次。

另一个配套工具是 sync.Pool，但它的效果反直觉。对比「每次 make 一个新 buffer」与「从 pool 取」：

BenchmarkPoolGet-10       	  200000	        20.69 ns/op	      24 B/op	       1 allocs/op
BenchmarkMakeEach-10      	  200000	         0.3323 ns/op	       0 B/op	       0 allocs/op

MakeEach（make([]byte, 4096)）反而更快、零分配——因为这块 buffer 不逃逸，编译器把它放在栈上，连分配都省了。而 pool.Get().([]byte) 的类型断言把 any 拆回 []byte，引入了一次接口装箱开销。

结论：sync.Pool 只在对象「真的逃逸」且「构造成本高」时才划算。它治的是逃逸的后果，不是逃逸本身；如果对象本就不逃逸，用它纯属加开销。

6.1.9 使用边界

三点必须说清：

1. **逃逸分析结论会随编译器版本变化。**本节的输出来自 go1.27.0；换版本、换 -l、换内联策略，结论可能不同。别把 -m 输出写进单元测试断言。
2. **不要为了「零逃逸」把代码写丑。**逃逸是性能问题，不是正确性问题。只在基准证明它是瓶颈时才改。
3. **-m 输出是提示，不是规范。**编译器没有义务保证「某写法一定不逃逸」——语言层面只保证语义，栈/堆是实现细节。

还要补一句「什么时候不用管逃逸」：如果一个函数每秒只被调用几十次，它的逃逸开销在整体性能里根本不可见。逃逸优化应该排在「先测量」之后——用 go test -benchmem 找到 allocs/op 异常的那几处，再动手。在没测量之前做的逃逸优化，多半是在给编译器添乱。

一句话收束：**逃逸分析的判据只有一条——值的地址会不会离开生它的函数。**记住这条，再配 -gcflags='-m -l' 实测确认，就不用背「什么会逃逸」的长清单了。

阅读导航：上一节：5.3 可见性陷阱与 -race 实测 · 下一节：6.2 GC 调优与 GOGC/GOMEMLIMIT 。