Go语言中没有运行时主动缩容，仅goroutine退出时整体释放；栈增长在函数调用前通过stackguard0（距栈顶约8KB）预判触发，超限即调runtime.morestack整栈复制搬家。
Go 语言中没有“栈缩容”这回事，函数返回后栈内存不会回收，只在 goroutine 彻底退出时归还给 runtime 缓存；所谓“栈增长”，也不是爆栈才反应，而是调用前靠 stackguard0 预判——差约 8KB 就搬整个栈。
为什么 runtime.morestack 会高频出现？
这不是栈“快满了”的警告，而是扩容已发生多次的证据。它说明你代码里存在持续触发栈检查的模式。
- 典型场景：
deepRecursive(n int)每层都压入新帧，每层调用前都触发stackguard0检查，只要剩余空间不足就跳转到runtime.morestack - 容易被忽略的二次扩容：在
defer函数体内再声明大数组（如var buf [4096]byte），会导致该defer执行时再次触发扩容 - 性能影响：每次扩容都要
copystack、重写所有指针、释放旧栈，停顿时间随栈大小线性增长；pprof top里看到runtime.growstack占比高，基本就是这个原因
stackguard0 不是栈顶，别把它当水位线
它离当前栈顶约 8KB，是编译器预设的“安全缓冲区”。SP 落到它下面，不是表示“只剩 8KB”，而是“接下来这个函数很可能放不下”。
- 编译器静态分析决定是否插入检查：比如
var x [65536]byte，哪怕函数只有一行赋值，也会因帧大小超限，在入口直接 panic，根本不会走到stackguard0判断那步 - 递归函数不“累积压力”，而是“逐层预判”：第 100 层调用前检查，发现当前栈剩 7KB，立刻扩容，不是等到第 101 层才动
- WASM 目标下
_StackMin可能只有 1KB，stackguard0缓冲更薄，本地测试通过不代表部署不出问题
怎么确认是不是栈在增长，而不是 goroutine 泄漏？
看 runtime.ReadMemStats().StackInuse，不是看 goroutine 数量。前者涨得快，后者未必变——短命 goroutine 深递归照样吃内存。
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap，然后top -cum -focus=morestack：如果大量调用链是walk → runtime.morestack → runtime.newstack，就是栈问题 -
GODEBUG=gctrace=1启动时若频繁打印stack growth，说明小 goroutine 正扛着大局部变量跑 - 别信
runtime/debug.Stack()显示的地址范围变小：那只是快照，不代表内存已释放；goroutine 没 exit，栈块就还在
真正难处理的不是“怎么扩容”，而是“为什么必须扩容”——局部变量逃逸不准、闭包捕获过大结构体、递归没设深度限制，这些才是根因；runtime 只负责搬家，不负责帮你改逻辑。
