Go栈扩容在函数调用前预判触发，非爆栈时；通过stackguard0（距栈顶约8KB）检查SP，超限即调runtime.morestack整栈复制搬家；无运行时主动缩容，仅goroutine退出时整体释放。
Go 的栈扩容不是“用完再扩”，而是在每次函数调用前就预判是否够用；它不拼接段，而是整块搬家复制，且不会自动缩容。
栈扩容在函数调用前就触发，靠 stackguard0 预判
Go 运行时并不等栈真正溢出才反应。编译器会在可能消耗较多栈空间的函数入口插入检查逻辑：比较当前栈指针 SP 与 stackguard0（一个距栈顶约 8KB 的安全缓冲区边界）。一旦 SP ，立刻跳转到 runtime.morestack 启动扩容流程。
这意味着：
- 哪怕函数只多用 1 字节，只要编译器估算该帧需要空间 > 当前剩余，就会触发整栈复制
- 循环里反复声明大数组（如
var buf [4096]byte）极易命中该检查，不是“运行中慢慢压栈”，而是一次调用就判定超限 - 递归函数每层调用都走这套检查，深度达数百层时，
runtime.morestack在 pprof 中会高频出现
扩容本质是“搬家”，不是原地 realloc
Go 自 1.3 起使用连续栈（contiguous stack），扩容时不会拼接新段，而是：
- 调用
stackalloc分配一块更大的内存（初始 2KB → 4KB → 8KB → … 到 64KB 后每次 +64KB） - 用
memmove将旧栈全部内容复制过去 - 更新
g.stack.lo/g.stack.hi、寄存器中的SP/BP，以及所有栈上可追踪指针（如&x） - 释放旧栈内存（但不立即还给 OS）
注意：unsafe.Pointer 算出的地址（如 unsafe.Add(unsafe.Pointer(&x), 8)）无法被运行时识别，扩容后直接失效；uintptr 存储栈地址也同理——这是最易踩的坑。
没有主动缩容，只有 goroutine 退出时整体释放
Go 当前**没有运行时主动收缩栈的机制**。所谓“栈缩小”只发生在一种情况：goroutine 彻底退出。此时栈内存归入 stackpool 或 stackLarge 缓存，供后续 goroutine 复用，但不会返还操作系统（除非 GC 决定回收整个 span）。
常见误解：
-
runtime.Stack(buf, false)显示栈地址范围变小 ≠ 栈缩容了，只是快照不可比 - GC 不会因栈空闲就触发缩容；休眠中的 goroutine（如阻塞在
channel上）也不会自动降栈大小 - 频繁创建/退出 goroutine 会导致
StackSys持续升高，表现为内存残留，而非泄漏
怎么确认代码正在频繁扩容？别看 panic，要看信号
等到 fatal error: stack overflow 或 runtime: goroutine stack exceeds 1000000000-byte limit 才发现，已经晚了。应提前观察运行时信号：
- 启动时加
GODEBUG=gctrace=1，看到类似stack growth: g[123] grew stack from 2048 to 4096 bytes就是明确信号 - 用
go tool trace抓取runtime.morestack事件，看频次和调用栈上下文 - 写个测试函数，对比
runtime.ReadMemStats().StackSys前后值，增长量 > 几 KB 就说明有实际扩容发生 -
go tool compile -S main.go | grep morestack快速筛查哪些函数被插了检查指令
真正难调试的，是那些没报错、但 runtime.morestack 占 CPU 5%+ 的场景——往往藏在初始化函数或 defer 链里，且和局部变量逃逸分析交织在一起。
