Go的goroutine栈扩容不是无限的，而是仅在函数调用前通过stackguard0检查触发“整体搬家”式复制；单帧过大、递归过深或跨CGO边界会直接panic，不扩容。
go 的 goroutine 栈不是“无限扩容”，而是按需复制搬家，且只在函数调用边界触发；一旦单帧过大、递归过深或跨 cgo 边界，立刻 panic，不给商量余地。
栈扩容只发生在函数调用前，不是运行中实时检测
Go 不会在 for 循环里、数组赋值中途或 defer 执行时检查栈是否够用。它只在每次函数调用入口处插入一条检查指令：CMP SP, stackguard0——如果当前栈指针 SP 已低于 stackguard0（约 8KB 安全缓冲区），就跳转到 runtime.morestack 开始扩容。
这意味着：
- 一个函数声明
var buf [8192]byte，哪怕还没执行到那行，只要编译器判定该帧需要超限空间，调用前就直接 panic - 递归函数每层都触发一次检查，但不会“累积到快爆了才扩”，而是“预判下一层放不下，马上搬”
-
defer函数体内再调用大栈函数，可能引发二次扩容，形成嵌套复制，延迟毛刺明显
扩容本质是“整体搬家”，不是原地 realloc
Go 1.3+ 使用连续栈机制：扩容时调用 stackalloc 申请一块新内存（初始 2KB → 4KB → 8KB…上限 1GB），把旧栈内容完整 memmove 过去，再批量修正所有栈上指针（包括 SP、BP 和 g.stack.lo/hi）。
这个过程带来几个硬约束：
- 扩容瞬间有停顿，pprof 中
runtime.newstack占比突增，往往说明某函数被高频调用且帧偏大 - 旧栈不能立即释放，得等所有引用更新完毕，导致短期内存双倍占用
- 局部变量是否逃逸会影响帧大小：逃逸失败时编译器反而多留栈空间防溢出，比如
&buf[0]传参后，整个buf可能被抬升到堆，但若逃逸分析不准，栈帧仍按大数组预留
哪些操作会绕过扩容逻辑，直接 panic
栈扩容依赖编译器插入的调用检查，但以下场景无法触发或不可控：
-
cgo调用：C 函数使用系统栈，Go 运行时不管理，也不扩容，混用时极易崩溃 - 单帧过大：如闭包捕获大结构体、函数内声明
var x [65536]byte，所需空间超过当前栈剩余 + guard 区，直接fatal error: stack overflow - 递归深度超限：即使每层只用几十字节，调用链 >10k 层也可能因 guard page 预留和段分配开销耗尽内存，报
runtime: goroutine stack exceeds 1000000000-byte limit -
//go:nosplit函数内调用任何可能扩容的函数（如fmt.Sprintf、append），会触发fatal error: stack split at bad time
怎么观察和验证真实栈行为
别猜，用工具定位：
- 加
GODEBUG=gctrace=1启动，看到大量scvg或stack growth日志，说明小 goroutine 在扛大数据 - 用
runtime.Stack(buf, true)捕获所有 goroutine 栈迹，重点关注重复出现的长调用链 - 设
GOTRACEBACK=crash触发 panic，输出含各帧大小估算（非精确字节，但能看出哪层占得多） - 构建时加
go build -gcflags="-m -l"，看逃逸日志里有没有moved to heap或escapes to heap，反向推断栈帧压力
真正可控的点其实很少：递归逻辑尽量转成迭代 + 显式栈；大临时数据优先走堆（让逃逸分析生效）；CGO 边界前后主动切 goroutine；其余交给 runtime，别硬碰 runtime/debug.SetMaxStack 这类调试接口。
