函数调用的瞬间：栈帧、拷贝栈与逃逸分析
每次调用函数，CPU 和运行时到底在忙什么？答案藏在一块叫栈帧（stack frame）的内存里。理解它，才能理解 Go 为什么敢给每个 goroutine 只发 8KB 的"启动资金"，以及"逃逸分析"到底在分析什么。
栈帧里装了什么
一次函数调用 = 在 goroutine 的栈上压入一块连续内存，布局如下（栈向低地址生长）：
text
高地址
┌──────────────────┐
│ 调用方传入的参数 │ ← caller 写入
│ 返回值槽位 │ ← caller 预留空间, callee 填写
│ 返回地址 (PC) │ ← 函数跑完跳回哪里
│ 局部变量 │ ← callee 自己的地盘
└──────────────────┘
低地址 (SP 栈指针)有个设计细节值得品味：返回值槽位由调用方预留。这就是 Go 多返回值零额外开销的秘密------返回值不是"弹出来"的，而是被调方直接写回调用方早就备好的位置。
Go 1.17 起 amd64 平台切换为寄存器优先传参（前 9 个整数参数走 AX、BX、CX 等寄存器），放不下的才走栈。但"调用方准备参数、预留返回值槽位"的语义不变。
动手验证：看着栈帧一层层叠起来
go
package main
import (
"fmt"
"runtime"
)
//go:noinline
func add(a, b int) int {
return a + b
}
//go:noinline
func stackDepth(depth int) int {
if depth == 0 {
// runtime.Callers 返回当前调用栈的 PC 序列, 帧数随递归深度增长
pcs := make([]uintptr, 64)
n := runtime.Callers(1, pcs)
frames := runtime.CallersFrames(pcs[:n])
count := 0
for {
_, more := frames.Next()
count++
if !more {
break
}
}
return count
}
return stackDepth(depth - 1)
}
//go:noinline
func bigFrame() int {
// 未逃逸的大数组直接在栈帧上分配, 帧大小可达 2KB+
var buf [256]int
buf[0] = 1
buf[255] = 2
return buf[0] + buf[255]
}
func main() {
// 1. 每次调用压入一个栈帧: 参数 + 返回值槽位 + 返回地址 + 局部变量
fmt.Printf("1. add(3, 4) = %d\n", add(3, 4))
// 2. 递归 N 层 -> 栈上叠 N 个帧
shallow := stackDepth(2)
deep := stackDepth(8)
fmt.Printf("2. 递归 2 层帧数 = %d, 递归 8 层帧数 = %d, 随深度增长: %v\n",
shallow, deep, deep > shallow)
// 3. goroutine 栈 8KB 起步, 按需倍增, 64 位默认上限 1GB
fmt.Printf("3. bigFrame() = %d (栈帧上的 2KB 局部数组)\n", bigFrame())
fmt.Printf(" 栈上限默认 %d bytes\n", 1<<30)
// 4. 扩容 = 拷贝栈: 分配 2 倍新栈 -> 拷贝旧帧 -> 修正指针 -> 释放旧栈
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("4. 当前 StackInuse = %d KB\n", m.StackInuse/1024)
// 5. 未逃逸变量随函数返回自动回收(栈指针回退), 零 GC 成本
p := new(int)
*p = 42
fmt.Printf("5. 栈分配 vs 堆逃逸: 未逃逸的变量回收无需 GC 介入 (p = %d)\n", *p)
}运行输出：
text
1. add(3, 4) = 7
2. 递归 2 层帧数 = 6, 递归 8 层帧数 = 12, 随深度增长: true
3. bigFrame() = 3 (栈帧上的 2KB 局部数组)
栈上限默认 1073741824 bytes
4. 当前 StackInuse = 224 KB
5. 栈分配 vs 堆逃逸: 未逃逸的变量回收无需 GC 介入 (p = 42)逐条解读
第 2 行 最有说服力：递归 2 层时栈上 6 帧（含 main 和 runtime 入口的固定帧），递归 8 层时 12 帧------每层递归精确对应一个栈帧 ，不多不少。runtime.Callers 把看不见的调用过程变成了可数的数字。
第 3 行 ：[256]int 的局部数组约 2KB，直接活在栈帧上。函数返回时 SP 指针一回退，这块内存就"回收"了------没有 GC，没有 free，成本约等于零。
第 4 行 ：StackInuse 只有 224KB。即使程序跑了很多调用，栈内存依然是 KB 级------因为帧随函数返回即时释放。
Go 的栈：8KB 起步，会自己长大
C 线程的栈是固定 1~8MB，一百万个线程就是 TB 级内存，想都别想。Go 的玩法完全不同：
- 初始 8KB：一百万 goroutine 的栈启动成本才 8GB 虚拟地址空间（实际按需提交物理页）；
- 按需倍增 ：每个函数入口有
morestack序言检查，发现空间不够就向运行时申请 2 倍大的新栈； - 有上限 ：64 位默认 1GB（
debug.SetMaxStack可调），超限报goroutine stack exceeds limit。
拷贝栈：扩容的四步曲
Go 1.3 起采用连续栈 + 整体拷贝策略。栈不够用时：
- 分配 2 倍大小的新栈段；
- 旧栈所有帧原样拷贝过去；
- 修正所有指向旧栈的指针（局部变量地址全变了！）；
- 释放旧栈，继续执行。
第 3 步的影响深远：Go 栈上对象的地址不是恒定的，栈一扩容就搬家。这正是 CGO 规则里"不能把 Go 栈上变量的指针长期交给 C 保存"的根本原因------C 代码攥着的地址，可能下一次扩容就失效了。
早期 Go 用的是分段栈（segmented stack），没有拷贝成本，但存在"热分裂"抖动：循环里反复跨段会不停申请释放栈段。拷贝栈就是为了根治它。
逃逸分析：栈与堆的分界线
栈分配这么香，那什么决定变量能不能留在栈上？答案是编译期的逃逸分析：
| 去向 | 回收方式 | 成本 |
|---|---|---|
| 栈（未逃逸） | SP 回退，即时 | ≈ 0 |
| 堆（已逃逸） | GC 标记清扫 | 摊销 GC CPU + 写屏障 |
常见逃逸诱因：
- 返回局部变量的指针；
- 值装进接口（上一篇讲的装箱）；
- 闭包捕获的变量比函数活得久；
- 大对象超过栈分配阈值；
fmt.Println这类...any参数的调用。
诊断工具一句话：go build -gcflags='-m -m'，每个变量的逃逸决策和理由全打出来。性能调优先看它。
实战启示
- 能不返回指针就不返回------让小对象死在栈帧里，是最便宜的内存管理；
- 深递归改迭代------栈虽会涨，1GB 上限下未优化的深递归（比如树的 DFS）照样爆；
- 火焰图里看到
morestack热点 = 栈在频繁扩容，考虑减帧或改堆分配。
小结
| 认知 | 一句话 |
|---|---|
| 栈帧 | 参数 + 返回值槽位（调用方预留）+ 返回地址 + 局部变量 |
| 传参 | Go 1.17+ 寄存器优先，栈布局语义不变 |
| 栈增长 | 8KB 起步、倍增扩容、默认上限 1GB |
| 拷贝栈 | 扩容修正全部栈指针 → 栈上地址不恒定，CGO 传指针需谨慎 |
| 逃逸 | 未逃逸零 GC 成本；-gcflags='-m' 是优化入口 |