Go goroutine栈初始2KB，通过分段栈和调用边界触发的栈分裂扩容，但非无限；递归过深、单帧过大或CGO调用易致stack overflow panic。
Go 的 goroutine 栈是自动扩容的，但不是“无限”或“无代价”
Go 运行时对每个 goroutine 使用分段栈（segmented stack），初始栈大小为 2KB（Go 1.14+ 在 Linux/macOS 上统一为 2KB；Windows 稍有差异），当检测到栈空间不足时，会分配新段并调整栈指针，实现“扩容”。这不是传统 C 风格的连续栈 realloc，而是通过栈分裂（stack split）机制完成的——关键在于：它只在函数调用边界触发，且依赖编译器插入的栈溢出检查（stack guard check）。
这意味着：runtime.stackGuard 不是你手动调的接口，goroutine 也不会在循环里或大数组分配时实时扩容。常见误解是“栈会按需增长到任意大小”，实际中一旦触发扩容失败（如内存耗尽、嵌套过深、或跨 CGO 边界），就会直接 panic: runtime: out of memory 或 fatal error: stack overflow。
为什么递归深度大时仍会 panic: stack overflow
Go 的栈扩容发生在函数调用前的栈空间检查阶段，但每次扩容需要预留“安全余量”（guard page + 新段开销），且新段也是固定大小（目前约 2–4KB）。如果递归函数本身帧很大（比如带大闭包、大量局部数组），或调用链极深（>10k 层），即使总栈用量未超内存上限，也可能因频繁分配段失败或无法满足单次调用所需最小空间而崩溃。
-
go run -gcflags="-S" main.go可查看编译器是否为函数插入了CALL runtime.morestack_noctxt（表示该函数可能触发栈检查） - 闭包捕获大结构体、或函数内声明
var buf [8192]byte这类大数组，会导致单帧过大，绕过常规扩容逻辑，直接触发栈溢出 - CGO 调用（
import "C"）中的 C 函数使用系统栈，不受 Go 运行时管理，此时 Go 栈不会为其扩容，容易因栈混用导致崩溃
如何观察和调试栈相关问题
不依赖猜测，用运行时工具定位真实瓶颈：
立即学习“go语言免费学习笔记（深入）”；
- 加
GODEBUG=gctrace=1启动程序，若看到大量scvg或stack growth日志，说明栈分配频繁，可能是小 goroutine 承载了本该用堆分配的大数据 - 用
runtime.Stack(buf, true)捕获当前所有 goroutine 栈迹，重点关注长调用链或重复出现的函数名 - 设置
GOTRACEBACK=crash并触发 panic，可输出完整栈帧及各帧大小估算（注意：不是精确字节数，但能看出哪一层占得多） -
pprof.Lookup("goroutine").WriteTo(w, 1)导出 goroutine profile，配合go tool pprof查看栈深度分布
真正可控的“栈管理”只有两条路：避免深栈，或改用堆
Go 没有提供 runtime.GrowStack 或类似 API，也不鼓励手动干预。所谓“管理”，本质是设计选择：
- 把深度递归转成显式栈（
stack []interface{}+for循环），让数据落在堆上，完全规避栈限制 - 拆分大函数：把长逻辑按职责切分，减少单帧局部变量体积；尤其避免在 goroutine 函数内声明 >2KB 的数组或结构体
- 确认是否真需要 goroutine：IO 密集型任务用
go fn()没问题，但 CPU 密集+深调用场景，不如用普通函数+池化sync.Pool复用中间结构 - 若必须处理超深嵌套（如解析巨型 JSON/YAML），优先用流式解析器（
json.Decoder）而非json.Unmarshal全量加载，后者会在栈上构造临时解析树
栈扩容机制本身是透明的，但它的边界由编译器插桩、运行时段管理、以及底层 OS 内存策略共同决定。越想“控制”，越要远离栈——把数据放堆上，把控制流拉平，才是 Go 式解法。
