Go栈扩容非无限增长，而是在函数调用前通过SP与stackguard0比较预判空间不足即触发runtime.morestack；若单帧需求超1GB上限或cgo/大数组绕过检查，则直接panic。
栈扩容不是“自动无限增长”，而是调用前预判失败就 panic
Go 的 goroutine 栈不会在运行中实时检测空间是否够用，只在函数调用入口插入 CMP SP, stackguard0 检查。一旦编译器判定当前帧所需空间（含局部变量 + 调用开销）超过剩余栈 + 约 8KB 安全缓冲区，立刻跳转 runtime.morestack；若新栈仍不够（比如单帧需 1MB），不尝试二次扩容，直接 fatal error: stack overflow。
- 常见错误现象：
runtime: goroutine stack exceeds 1000000000-byte limit—— 不是没扩，是扩到 1GB 还放不下 - 典型触发点：函数内声明
var buf [65536]byte、闭包捕获大结构体、深度递归（>10k 层） - 注意：
//go:nosplit函数里调用任何可能扩容的函数（如fmt.Sprintf），会报stack split at bad time
扩容本质是“搬家”，不是 realloc，复制停顿真实存在
每次扩容都调用 stackalloc 在堆上分配新内存（2KB → 4KB → 8KB → … → 64KB 后每次 +64KB），把旧栈内容完整 memmove 过去，再批量修正所有栈上指针（SP、BP、g.stack.lo/hi）。这个过程不可中断，且旧栈不能立即释放——得等所有引用更新完，短期内存占用翻倍。
- 性能影响：pprof 中高频出现
runtime.morestack或runtime.growstack，说明某函数被频繁调用且帧偏大 - GC 影响：栈内存计入
MemStats.StackSys，短生命周期 goroutine 大量创建/退出时，栈内存不会立刻归还，依赖 GC 扫描回收 - 调试方法：用
runtime.ReadMemStats对比前后StackSys值，或启用GODEBUG=gctrace=1观察STK字段变化
cgo 和大数组是绕过扩容逻辑的“硬崩溃”场景
cgo 调用完全脱离 Go 运行时栈管理，C 函数使用系统栈，Go 栈不会为其预留或扩容空间；而大数组（如 [8192]byte）在编译期就被判定为单帧超限，调用前检查直接失败——这两类问题都不会触发 morestack，而是无条件 panic。
-
import "C"后调用 C 函数时，务必确保其栈消耗可控；避免在 cgo 边界附近做深度递归或大局部变量分配 - 大数组声明不要写死尺寸，改用
make([]byte, 8192)让其逃逸到堆；或用unsafe.Slice+mmap手动管理（需谨慎） - 闭包捕获大结构体时，显式用指针传参（
&bigStruct），避免值拷贝放大栈帧
别信“栈会自己长大”，真正可控的只有堆分配和调用链控制
没有 API 能手动触发或干预栈扩容时机，runtime/debug.SetMaxStack 只设上限（默认 1GB），不影响扩容行为；所谓“栈缩容”也仅在 goroutine 返回后、使用率
立即学习“go语言免费学习笔记（深入）”；
- 真正有效的做法只有两个：把本该放堆的数据放堆（加
&、用make、让逃逸分析生效），或把深调用链拆成循环+状态机 - 用
go run -gcflags="-S"查看函数是否含CALL runtime.morestack_noctxt，确认编译器是否插入了栈检查 - 线上服务遇到栈相关毛刺，优先查 pprof goroutine profile 的栈深度分布，而不是猜哪行代码“占得多”
