Go栈扩容是函数调用前由编译器预埋的stackguard0检查触发的整栈复制搬迁，非实时响应；一旦SP跌破安全水位线，即调用runtime.morestack分配新栈、memcpy旧内容、重定位指针并释放旧栈。
Go 的 runtime.morestack 不是“栈快爆了才救火”，而是编译器在函数入口**预埋的守门人**——它不等栈真正溢出，而是在每次调用前就查 SP（栈指针）是否已跌破 stackguard0 这个安全水位线。触发即搬家，不是微调，更不是原地扩容。
为什么每次函数调用都要检查 stackguard0？
因为 Go 编译器在生成代码时，会为每个可能消耗较多栈空间的函数（比如含大数组、多层嵌套闭包、递归入口）自动插入一段汇编检查逻辑。这段逻辑本质就是一条比较指令：cmp sp, stackguard0，紧接着是条件跳转。只要 sp < stackguard0，立刻跳进 runtime.morestack 启动扩容流程。
这不是运行时动态探测，而是编译期静态分析 + 插桩的结果。所以：
- 即使函数只声明了
var buf [4096]byte，哪怕没用到，也会被算入栈帧需求，触发检查 - 闭包捕获大结构体、
defer函数内再分配大栈空间，都可能让编译器高估该次调用所需栈大小 - 没有“刚好够用”的概念：差 1 字节，也得整栈复制
morestack 汇编里实际干了什么？
进入 runtime.morestack 后，汇编代码做的第一件事不是 malloc，而是保存当前寄存器上下文（特别是 SP、BP、PC），然后调用 runtime.newstack。关键行为包括：
- 计算新栈大小：通常是当前栈大小的 2 倍（但不超过
maxStack = 1GB） - 调用
runtime.stackalloc分配新内存块，不是mmap就是复用运行时栈池 - 执行
memmove把旧栈全部内容（含所有局部变量、返回地址、_defer链）拷过去 - 修正所有栈上指针：更新
g.stack.lo/g.stack.hi，重写寄存器中的SP和BP，甚至遍历并重定位每个_defer结构体里的栈地址字段 - 最后跳回原函数入口，仿佛什么都没发生过
整个过程由汇编+少量 C 实现，不经过 GC 或调度器主循环，保证原子性。
哪些场景会让 morestack 频繁出现？
高频调用 runtime.morestack 是性能毛刺的重要信号，常见于：
-
for循环体内反复声明大数组，如buf := [8192]byte{}—— 每次迭代压栈 8KB，极易逼近stackguard0 - 深度递归且每层都带较大栈帧（如每层都 new 一个 map 或 slice 头）
- 函数签名看似轻量，但内部通过闭包捕获了大对象，编译器把捕获变量也算进栈帧
- 使用
runtime.Stack或 pprof 抓取 goroutine 栈时，若看到runtime.growstack占 top3，基本可断定是栈管理热点
注意：GODEBUG=gctrace=1 不会显示 morestack，要用 go tool trace 才能精准定位每次调用的时间点和调用栈。
栈增长后，旧栈内存怎么处理？
旧栈内存不会立即释放，而是交还给运行时的栈内存池（stackpool），等待后续 goroutine 复用。这个池按 size 分桶（如 2KB、4KB、8KB…），复用时免去系统调用开销。
但这里有个容易被忽略的细节：栈不会自动收缩。即使函数返回、局部变量失效、SP 回退，底层分配的内存块仍保留在池中。只有当 goroutine 退出，且该栈块长时间未被复用，才会被 GC 归还给操作系统。
这意味着：写一个“先猛增、再空跑”的协程（比如初始化时分配大 buffer，之后只做小计算），它的栈占用会长期卡在高位，runtime.ReadMemStats().StackSys 不会回落——这不是 bug，是设计使然。
