Go 的 goroutine 栈是按需分配的，不是固定大小
Go 不像 C 那样给每个线程预分配 2MB 栈空间，而是初始只给 goroutine 分配 2KB（1.14+ 是 4KB）栈内存。它用连续栈（continous stack）机制，在栈快满时自动扩容——不是复制到新地址再拼接（老式分段栈），而是直接申请一块更大的内存，把旧栈内容搬过去，然后更新所有指针。
这意味着：小函数、无深度递归的场景几乎不触发扩容；但一旦出现深层嵌套调用、大局部变量（比如大数组）、或无意中逃逸的闭包捕获大量数据，就容易在运行时多花一次 runtime.stackalloc + memmove 的开销。
- 常见错误现象：
fatal error: stack overflow很少见，但你会看到runtime.morestack在 pprof 中占比突增 - 使用场景：HTTP handler 里做深度 JSON 解析、递归解析 AST、或用
defer套太多层时容易踩中 - 参数差异：栈上限默认是
1GB（由runtime.stackHi控制），但实际很少跑到那么高——多数问题出在第 1–3 次扩容上
局部变量是否逃逸，直接影响栈分配时机
Go 编译器通过逃逸分析决定变量放栈还是堆。放在栈上的变量，生命周期随函数返回自动结束；一旦逃逸，就得走堆分配 + GC 路线。但很多人忽略一点：**逃逸本身不触发栈扩容，但逃逸失败（比如想逃逸却因指针运算被判定为“可能越界”）会导致编译器保守地扩大栈帧预留空间**。
例如，make([]int, 1000) 在栈上分配没问题，但 &buf[0] 后又传给另一个函数，就可能让整个 buf 被抬升到堆——而如果没成功逃逸，编译器反而会多留几百字节栈空间防溢出。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：明明没递归，
pprof显示runtime.newstack占 CPU 5%+，且集中在某个初始化函数 - 验证方法：加
go build -gcflags="-m -l"看变量逃逸日志，重点找moved to heap或escapes to heap - 性能影响：栈帧变大 → 缓存行利用率下降；多次扩容 → 内存碎片 + 搬移延迟；两者叠加会让 P99 延迟毛刺明显
手动控制栈行为的边界很窄，别硬刚 runtime
有人想用 //go:nosplit 禁用栈扩容来“保确定性”，这基本是陷阱。该指令只禁用当前函数的 morestack 检查，但一旦调用任何可能扩容的函数（比如 fmt.Sprintf、append、甚至某些 syscall 封装），就会 panic： fatal error: stack split at bad time。
真正可控的点只有两个：一是用 runtime/debug.SetMaxStack 调整单个 goroutine 上限（仅调试用，生产禁用）；二是写递归逻辑时主动转成迭代 + 显式栈（[]interface{} 或自定义结构体），把内存控制权拿回来。
- 容易踩的坑：
//go:nosplit函数里调了log.Printf—— 表面编译过，运行必崩 - 替代方案：对深度遍历场景，用
for+slice模拟调用栈，比依赖 runtime 扩容更稳 - 兼容性注意：Go 1.22 开始，
runtime.stackalloc内部改用 mcache 分配，扩容延迟更平滑，但无法消除首次分配抖动
pprof 里看栈行为，重点盯这三个指标
别只看 top 函数耗时。要确认栈是否成瓶颈，得进 go tool pprof 后输入 web 或 peek runtime.morestack，再结合符号过滤：
-
runtime.morestack自身耗时高 → 扩容频繁，查调用方是否有隐式递归或大数组 -
runtime.newstack分配次数多 → goroutine 创建密集（如每请求起一个），考虑复用 worker pool -
runtime.stackalloc在火焰图底部反复出现 → 栈帧碎片化严重，可能是小对象逃逸失败导致预留空间浪费
复杂点在于：这些函数不报错、不打日志、也不进 trace（除非开 GORACE=1）。你得靠 pprof 主动挖，而不是等它崩给你看。
