go 的 goroutine 栈采用动态增长策略而非固定大小，初始为2kb，不足时分配新栈并复制数据，但不自动收缩；增长由编译器插入的边界检查触发，不可手动控制。
Go 的 goroutine 栈为什么不是固定大小
因为 Go 运行时需要在轻量级协程和内存效率之间做权衡——固定栈（比如 2KB 或 8KB）太浪费或太危险，而动态增长能兼顾启动快、开销小、不轻易爆栈。但这个“动态”不是 malloc 那种自由伸缩，而是分段分配 + 栈拷贝的组合策略。
- 每个新 goroutine 初始栈大小是
_StackMin（当前 Go 版本为 2KB），不是 1B 也不是 8MB - 当栈空间不足时，运行时会分配一块**新栈**（通常是原大小的 2 倍），把旧栈数据**完整复制过去**，再调整所有指针（包括寄存器和栈上变量的地址）
- 这个过程叫
stack growth，发生在函数调用前的栈检查点（如morestack函数入口），不是每次 push 都检查 - 栈不会自动收缩：即使函数返回、局部变量失效，栈顶位置回退，但底层分配的内存块仍保留，直到 goroutine 退出
什么时候会触发栈增长？看 runtime.morestack 的实际行为
它不靠“剩余空间告警”，而是依赖编译器在函数入口插入的栈边界检查指令。只要函数声明的栈帧需求超过当前可用空间，就跳转到 morestack。
- 典型触发场景：
func f() { x := [4096]byte{}; ... }—— 局部数组过大，编译期就能算出需约 4KB 栈，初始 2KB 不够 - 递归过深也会触发，但不是“第 N 层就崩”，而是某次调用预估栈帧 > 当前剩余空间时才增长
-
defer、recover、闭包捕获大变量都可能隐式增加栈需求，容易被忽略 - 注意：增长本身有开销（复制 + 指针重写），频繁增长（如每轮循环都逼近边界）会明显拖慢性能
如何观察栈增长是否发生
不能只看 runtime.Stack 输出的栈迹——它只显示当前帧，不反映历史增长。得靠运行时调试信号或 GC 日志。
- 启动程序时加
GODEBUG=gctrace=1，增长时会打印类似stack growth: g[123] grew stack from 2048 to 4096 bytes - 用
go tool trace分析，筛选runtime.morestack事件，看频次和时机 - 在关键路径上避免单次函数占用 >1KB 栈空间，尤其别在 hot path 里声明大数组或嵌套结构体
- 交叉编译目标平台影响实际栈大小（比如 wasm 下初始栈更小），测试环境要贴近部署环境
为什么不能手动控制 goroutine 栈大小
Go 故意不暴露栈大小配置接口，是因为运行时需要全程掌控栈生命周期——从分配、增长、指针重写到最终回收。开放控制会破坏安全假设。
立即学习“go语言免费学习笔记（深入）”；
-
runtime.Stack返回的是当前栈快照，不是可修改的句柄；debug.SetMaxStack是假的，早被移除，文档里也找不到 - 试图用
unsafe手动操作栈指针会导致fatal error: stack overflow或静默崩溃，因为 GC 和调度器依赖栈头元信息 - 真正可控的是 goroutine 数量与工作负载分布：如果大量 goroutine 都在做高栈消耗操作（如深度 JSON 解析），应考虑改用 channel + worker 模式摊薄单 goroutine 压力
- CGO 调用不受 Go 栈管理约束，其 C 栈独立且固定，
pthread_create默认栈大小（通常 2MB）可能成为瓶颈，需用pthread_attr_setstacksize调整
栈增长机制本身很稳健，但它的“隐形性”恰恰是最容易出问题的地方：你看不到它什么时候发生，也很难在压测中复现临界增长点。线上偶发的延迟毛刺，有时就是某个 goroutine 在第 7 次增长时卡住了几十微秒。
