Go 从 0 到精通 · 第 36 课：内存与逃逸分析基础

学习定位：这是整套 Go 教程的第 36 课，也是阶段六（高级进阶阶段）的第三课。
前置要求：已经完成第 35 课，理解 Go 的结构体、指针、函数调用、Benchmark 与反射基础。
本课目标：建立 Go 内存行为的基础认知，理解栈与堆的区别、什么是逃逸分析、哪些写法容易导致变量逃逸、值传递与指针传递分别意味着什么，并学会用 go build -gcflags="-m" 初步观察编译器的逃逸分析结果。

1. 本课你要解决的核心问题

前面你已经开始接触性能测试了，也学了项目结构、泛型和反射。接下来要补上一块非常关键的底层认知：Go 代码到底是怎么分配内存的。

很多性能相关的问题，最后都会落到下面这些判断上：

这个变量是在栈上还是堆上？
为什么我只是返回了一个指针，它就“逃逸”了？
结构体传值是不是一定比传指针慢？
这个函数为什么会触发更多 GC？
为什么反射、接口、闭包有时更容易产生额外分配？

如果这些问题完全没概念，你做性能优化时很容易出现两种情况：

靠感觉优化，方向常常不对
看到 “moved to heap” 这种编译器输出却不知道什么意思

这节课不是让你一上来就做底层黑魔法，而是帮你建立三个基本判断：

Go 里变量不只是“有值”，还有“存在哪”
编译器会根据使用方式决定放栈还是堆
堆分配通常更贵，因为它可能带来 GC 成本

2. 先建立直觉：栈和堆到底有什么区别

2.1 栈是什么

可以先把栈理解成：

当前函数调用过程中，临时使用的一块相对轻量、自动管理的内存区域。

典型特点：

分配和回收很快
生命周期通常跟函数调用相关
编译器更容易管理

例如一个普通函数里的局部变量，如果不会被外部继续使用，就很可能放在栈上。

2.2 堆是什么

可以先把堆理解成：

生命周期可能超出当前函数调用，需要由运行时统一管理的一块内存区域。

典型特点：

分配成本通常比栈高
不能随着当前函数结束直接回收
需要垃圾回收器（GC）参与管理

2.3 一个很粗糙但实用的理解

你可以先记成：

栈：更像“当前函数自己用的临时空间”
堆：更像“函数结束后还可能被别人继续用的空间”

这当然不是完整定义，但对入门判断很有帮助。

3. 不要死记“指针一定在堆上”

这是初学者最常见的误解之一。

很多人一学到指针，就会形成一个错误印象：

只要用了指针，数据就一定在堆上。

这不对。

Go 里变量放栈还是堆，不是由“你有没有写 * 或 &”单独决定的，而是由：

变量是否会在函数外继续存活
编译器能不能证明它只在当前作用域安全使用

共同决定的。

也就是说：

有些用了指针的值仍然可以在栈上
有些没写指针的值也可能逃逸到堆上

这点非常重要，因为后面很多判断都建立在这里。

4. 什么是逃逸分析

4.1 先说定义

逃逸分析（Escape Analysis）是编译器在编译阶段做的一项分析，用来判断：

一个变量能不能安全地分配在栈上，还是必须放到堆上。

4.2 “逃逸”是什么意思

所谓“逃逸”，你可以先理解成：

这个值的使用范围“逃出了”当前函数栈帧。

例如：

函数返回了局部变量的地址
局部变量被闭包捕获，函数结束后还要用
值被放进某些编译器无法证明局部安全的场景

这时编译器就可能决定：

这个变量不能只放栈上，得放堆上。

4.3 为什么编译器要做这个分析

因为如果一个变量本来可以安全放栈上，那就没必要上堆。

好处是：

分配更快
回收更简单
GC 压力更小

所以逃逸分析本质上是编译器帮你做的一种性能优化与安全判断。

5. 一个最经典的例子：返回局部变量指针

5.1 代码

package main

import "fmt"

func NewInt() *int {
    x := 10
    return &x
}

func main() {
    p := NewInt()
    fmt.Println(*p)
}

5.2 为什么这里会逃逸

x 是 NewInt 的局部变量。

按正常情况，NewInt 返回后，它的栈帧就该结束了。

但你返回了 &x，意味着：

main 里还要继续用这个地址
所以 x 不能随着 NewInt 结束一起消失

编译器就会把 x 放到堆上。

5.3 这不是 bug，而是 Go 的正常机制

很多新手会担心：

“返回局部变量地址不是危险的吗？”

在 C/C++ 里，这种事可能非常危险。

但 Go 编译器会通过逃逸分析把它安全地放到堆上，所以这段代码是安全的。

这就是 Go 语言层和底层实现配合的典型例子。

6. 对比：返回值和返回指针，不只是语法差异

6.1 返回值版本

func NewPointValue() Point {
    p := Point{X: 10, Y: 20}
    return p
}

6.2 返回指针版本

func NewPointPointer() *Point {
    p := Point{X: 10, Y: 20}
    return &p
}

6.3 这两者的差异要怎么理解

很多人会直觉认为：

返回值 -> 一定慢，因为要拷贝
返回指针 -> 一定快，因为只返回地址

这是非常危险的简单化结论。

真实情况是：

返回值可能完全不逃逸，编译器优化后很高效
返回指针可能导致堆分配和后续 GC 成本

所以性能不能只看“有没有拷贝”，还要看：

数据多大
生命周期多长
是否引入堆分配
是否影响缓存局部性和 GC

6.4 一条很实用的经验

小而短命的数据，传值常常并不差，甚至更好。

所以不要一上来就把所有结构体都改成指针。

7. 怎么看逃逸分析结果

Go 编译器可以把分析结果打印出来。

7.1 常用命令

1	go build -gcflags="-m"

如果想看更多信息：

1	go build -gcflags="-m -m"

7.2 示例代码

package main

func NewInt() *int {
    x := 10
    return &x
}

func main() {
    _ = NewInt()
}

运行：

1	go build -gcflags="-m"

可能看到类似输出：

1	./main.go:4:2: moved to heap: x

7.3 怎么读这类输出

moved to heap: x 的意思就是：

变量 x 原本是局部变量
但编译器判断它不能安全只待在栈上
所以把它放到了堆上

要注意：

具体输出内容会随 Go 版本变化
不同平台和编译优化也会影响细节

所以你要读的是“结论方向”，不是死记每一行字面格式。

8. 不返回指针，也可能逃逸

这是另一个很重要的认知点。

8.1 例子：放进接口

package main

import "fmt"

type User struct {
    Name string
    Age  int
}

func PrintAny(v any) {
    fmt.Println(v)
}

func main() {
    u := User{Name: "张三", Age: 18}
    PrintAny(u)
}

这里虽然没有显式返回指针，但把值传到接口、再交给 fmt.Println 之类的函数时，可能会引入逃逸。

8.2 为什么会这样

因为接口值会携带：

动态类型信息
动态值信息

而具体是否逃逸，取决于编译器能否证明这个值不会在更长生命周期里被使用。

8.3 这里最重要的不是背规则，而是建立警觉

你要知道：

逃逸不只是“返回地址”这一种情况
接口、反射、闭包、goroutine 都可能影响逃逸分析结果

9. 闭包为什么常常会导致逃逸

9.1 先看代码

package main

import "fmt"

func Counter() func() int {
    n := 0
    return func() int {
        n++
        return n
    }
}

func main() {
    next := Counter()
    fmt.Println(next())
    fmt.Println(next())
}

9.2 为什么 `n` 容易逃逸

因为 n 本来是 Counter 的局部变量。

但返回的匿名函数在 Counter 结束后还会继续使用它。

所以：

n 的生命周期已经超过了 Counter 调用本身
编译器通常会让它放到堆上

9.3 这和前面的“返回局部变量指针”本质类似

本质都是：

当前函数结束了
但某个局部值还得继续活着

这就是逃逸。

10. goroutine 也会影响生命周期判断

10.1 例子

package main

func main() {
    x := 42
    go func() {
        println(x)
    }()
}

10.2 为什么这里要小心

因为 goroutine 的执行时间不一定和当前函数同步。

编译器看到：

x 被另一个 goroutine 使用
这个使用可能持续到当前作用域结束之后

于是它更可能把相关变量放到堆上。

10.3 这也是并发代码更容易带来额外分配的原因之一

并发不仅带来调度、同步等成本，也常常让变量生命周期更复杂，从而影响逃逸分析。

11. 切片、map、channel 本身也是引用语义风格的值

这部分很容易让人理解混乱，所以要单独讲。

11.1 它们是值，但底层指向共享数据

例如切片：

1	s := []int{1, 2, 3}

切片变量本身是一个小结构，通常包含：

指向底层数组的指针
长度
容量

也就是说：

切片变量本身可以被复制
但多个切片值可能共享同一块底层数组

11.2 这和逃逸分析有什么关系

如果底层数据需要在更长生命周期里存在，相关分配也可能发生在堆上。

例如：

func MakeSlice() []int {
    s := make([]int, 100)
    return s
}

这里返回的是切片值，不是指针，但切片底层数组显然要在函数外继续存在，所以底层数据会有对应的堆分配考虑。

11.3 一个实用理解

不要把“有没有显式写指针”当成内存行为唯一判断依据。

Go 里很多复合类型即使语法上不是 *T，底层也会涉及共享数据和引用式行为。

12. 结构体传值 vs 传指针，正确比较方式是什么

这是 Go 里最容易被经验帖误导的话题之一。

12.1 传值的特点

1	func Process(u User) { ... }

特点：

会复制一份值
调用方和被调方互不影响
更容易理解和推理

12.2 传指针的特点

1	func Process(u *User) { ... }

特点：

传递的是地址
可以修改原对象
可能减少大对象拷贝
但也可能引入共享状态、逃逸和 GC 成本

12.3 该怎么选

不要问：

“传值好还是传指针好？”

而要问：

这个类型大不大？
我需不需要修改原对象？
生命周期会不会因此变长？
这样写会不会让 API 更难理解？

12.4 一个很实用的经验

对于：

小结构体
不需要修改原值
语义上像普通数据记录

优先传值通常没问题。

而对于：

很大的结构体
需要原地修改
需要避免大量复制

传指针可能更合适。

但最后仍然要靠测试和 Benchmark，而不是只靠口号。

13. 堆分配为什么常常更贵

理解这一点，才能明白为什么大家总说“减少逃逸有利于性能”。

13.1 分配本身更复杂

栈上的分配通常可以非常简单，因为跟函数调用过程强相关。

堆上的分配则需要运行时管理，通常更重。

13.2 回收要靠 GC

如果一个对象在堆上，等它不用了，并不能像栈那样随着函数退出自然回收。

它需要等待垃圾回收器识别“已经不可达”后再回收。

这意味着：

GC 需要扫描更多对象
GC 压力会上升
程序整体吞吐可能受影响

13.3 大量小对象尤其容易带来问题

很多时候真正拖慢程序的，不是某一个超大的对象，而是：

高频率创建
生命周期很短
数量又很多

这种模式会让 GC 很忙。

所以优化时常见目标之一就是：

减少不必要的短命堆对象。

14. 反射、接口、fmt 常常更容易带来分配

这部分你已经学过前置知识，现在可以把它们串起来看了。

14.1 为什么 `fmt.Println` 有时会带来更多开销

因为它是高度通用的：

接收可变参数
处理接口值
做格式化

这背后可能涉及：

接口装箱
额外分配
反射或动态处理路径

14.2 为什么反射常常更重

因为反射本来就是动态机制，需要：

包装类型和值
运行时判断
可能产生更多间接访问

14.3 这里的核心结论不是“不能用”

而是：

在普通业务里，这些额外成本通常可以接受
在高频热点路径里，就要更谨慎

这也是为什么性能优化总强调：

先找热点，再做针对性判断。

15. 一个最重要的工具：用编译器输出验证，不靠猜

前面都是概念，这里要落到实际动作上。

15.1 看逃逸

1	go build -gcflags="-m"

15.2 看性能

1	go test -bench . -benchmem

15.3 两者结合才有意义

例如你改了一个函数：

少了一个指针返回
改成传值

这时你应该：

用 -gcflags="-m" 看编译器是否减少了逃逸
用 Benchmark 看实际 ns/op、B/op、allocs/op 有没有变化

不要只看到一条 moved to heap 就马上下结论。

因为：

有逃逸不一定就是坏事
没逃逸也不一定整体更快

最终还是要回到数据。

16. 一个完整示例：对比值返回和指针返回

16.1 示例代码

package point

type Point struct {
    X int
    Y int
}

func NewPointValue(x, y int) Point {
    p := Point{X: x, Y: y}
    return p
}

func NewPointPointer(x, y int) *Point {
    p := Point{X: x, Y: y}
    return &p
}

16.2 你可以怎么分析

第一步，看逃逸：

1	go build -gcflags="-m"

第二步，写 Benchmark：

func BenchmarkNewPointValue(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = NewPointValue(10, 20)
    }
}

func BenchmarkNewPointPointer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = NewPointPointer(10, 20)
    }
}

第三步，看结果：

ns/op
B/op
allocs/op

16.3 你真正该学到什么

不是“返回值永远更快”或者“返回指针永远更快”，而是：

这类问题必须结合逃逸分析和基准测试一起判断。

17. 常见坑总结

17.1 看到指针就说“肯定更快”

不对。

指针可能减少拷贝，但也可能：

让对象逃逸到堆上
增加 GC 压力
增加共享状态复杂度

17.2 看到传值就说“肯定复制很慢”

也不对。

对于小对象，值复制常常便宜得多，而且更利于局部性和简单性。

17.3 把逃逸分析当成“越少越神”

有些逃逸是合理且必要的。

例如：

返回对象指针作为 API 设计的一部分
闭包天然需要延长变量生命周期

目标不是“绝对零逃逸”，而是：

减少不必要的逃逸。

17.4 只盯着 `moved to heap`

编译器输出只是线索，不是最终性能结论。

还要结合：

Benchmark
内存分配数据
实际热点路径

17.5 为了避免逃逸把代码写得很难懂

如果为了省一两个分配，把代码改得非常绕、可维护性很差，那通常不值得。

性能优化必须考虑成本收益比。

17.6 忘了接口、反射、闭包、goroutine 都可能影响逃逸

很多人只盯着“返回指针”，却忽略了这些更隐蔽的场景。

真正成熟的判断应该更全面。

18. 本课练习

练习 1：观察返回指针导致的逃逸

写两个函数：

一个返回 int
一个返回 *int

然后用：

1	go build -gcflags="-m"

观察它们的编译器输出差异。

练习 2：闭包捕获变量

写一个返回匿名函数的计数器：

1	func Counter() func() int

然后观察：

计数变量会不会逃逸
为什么会逃逸

练习 3：值传递 vs 指针传递

定义一个有 5～8 个字段的结构体，分别写：

传值版本处理函数
传指针版本处理函数

再写 Benchmark 对比它们的：

ns/op
B/op
allocs/op

练习 4：接口装箱观察