Go没有导出栈扩容函数，因为runtime.morestack是编译器在函数入口自动插入的汇编检查指令（cmp sp, stackguard0），触发时整栈复制搬家，非实时响应且不可手动调用。
Go 没有“栈空间自动增长函数”——runtime.morestack 不是你能调、也不该调的函数，它是编译器自动插入的检查跳转点，不是 API。
为什么找不到 stack grow / expand 这类导出函数
Go 运行时故意不暴露任何栈扩容控制接口。你查不到 runtime.GrowStack、runtime.ExpandStack 或类似函数，因为栈增长不是由用户代码触发的，而是由编译器在函数入口硬编码的一条汇编检查指令驱动的：CMP SP, stackguard0。一旦 SP 落到 stackguard0 之下，CPU 就跳转到 runtime.morestack（或其变体如 runtime.morestack_noctxt），整个过程对 Go 代码完全透明。
常见误解：以为加个 debug.SetMaxStack 就能调大，但这个函数早在 Go 1.5 就被移除，文档里根本不存在；runtime.Stack 只是快照输出，不能修改栈大小。
- 用
go tool compile -S main.go | grep morestack可确认哪些函数被插了检查 -
//go:nosplit函数里若调用了fmt.Sprintf等可能扩容的函数，会直接 panic，而不是“先检查再扩” - 试图用
unsafe手动操作栈指针（比如unsafe.Add(unsafe.Pointer(&x), 8)）会导致扩容后地址悬空，行为未定义
栈增长实际发生在函数调用前，不是函数执行中
它不会在 for 循环里、append 过程中或 defer 执行中途触发。只在每次函数调用的最开头检查——哪怕函数体第一行是 var buf [4096]byte，只要编译器算出该帧需约 4KB，而当前剩余栈 + guard 区不足，就会在 call 指令执行前就跳进 runtime.morestack。
立即学习“go语言免费学习笔记（深入）”；
- 递归函数每层调用都走一次检查，不是“累计 N 层后统一扩”，而是“第 N+1 层调用前预判放不下，立刻搬”
-
defer本身栈开销小，但如果 defer 的闭包捕获了大结构体（比如整个http.Request），这部分数据会随 defer 记录一起压栈，容易被忽略 - 局部数组声明（如
var x [65536]byte）是高频触发点：编译期就能确定帧大小，若 > 当前可用空间 + ~8KB guard 区，直接fatal error: stack overflow，不给扩容机会
扩容不是 realloc，是整栈 memcpy 搬家
Go 自 1.3 起弃用分段栈，改用连续栈（contiguous stack）。扩容时不是在原内存后面追加，而是：
- 调用
stackalloc分配新块（2KB → 4KB → 8KB → … 到 64KB 后每次 +64KB，上限默认 1GB） - 用
memmove把旧栈全部内容复制过去（包括所有局部变量、活跃的_defer链、寄存器值） - 修正
g.stack.lo/g.stack.hi、SP/BP 寄存器、以及所有可追踪栈指针（如&x） - 释放旧栈（但不立即还 OS，受 GC span 管理）
这意味着一次扩容耗时是 O(n)，且会带来明显毛刺。如果你在 pprof 中看到 runtime.morestack 占 CPU 高，基本等于你在 hot path 里反复触发大帧调用或深度递归。
没有缩容，只有 goroutine 退出时整体释放
Go 当前**没有运行时主动收缩栈的机制**。函数返回、局部变量失效、栈顶回退，底层分配的内存块仍保留。所谓“栈变小了”，只是 runtime.Stack 快照显示当前活跃帧范围缩小，不代表内存被回收。
- goroutine 阻塞在 channel 上、休眠、甚至执行
time.Sleep，栈内存都不会降 - 频繁创建/退出 goroutine 会导致
runtime.ReadMemStats().StackSys持续升高，这是正常复用行为，不是泄漏 - WASM 目标下
_StackMin可能为 1KB，测试环境必须和部署平台一致，否则扩容阈值差异会导致线上才暴露问题
真正需要警惕的，不是“栈会不会扩”，而是“它是否在不该扩的地方反复扩”——那往往意味着单帧过大、递归失控，或闭包无意捕获了不该带进栈的数据。
