Go 1.3起采用连续栈：初始2KB，扩容时复制旧栈并重定位指针，消除分段栈的hot split与GC扫描难题，但引入复制停顿；栈上限1GB，超限panic；defer/recover可靠，因运行时重定位_defer结构。
Go 1.3 之后，goroutine 栈不再分段，而是采用连续栈（contiguous stack）机制：每次扩容时分配一块两倍大小的新内存，拷贝旧栈数据，再释放旧栈。这不是优化“选择”，而是必须如此——分段栈在循环调用场景下会因频繁分裂/收缩导致严重性能抖动（hot split），Go 团队在 1.2 就已确认其不可接受。
为什么 go f() 合法但 go f 编译失败？
Go 规范明确要求 go 语句后必须是函数调用表达式（CallExpr），而非函数值。编译器在语法分析阶段就拒绝 go f，因为 f 是一个可寻址的函数值，不是调用动作本身。
-
go f()：合法，触发一次调用，运行时为该调用准备栈帧 -
go f：非法，缺少括号，不构成调用，编译器报错syntax error: unexpected newline, expecting ( -
go (f())：非法，括号内是求值结果（比如int），不是调用表达式
这个限制直接关联栈初始化时机：只有调用发生时，运行时才知道需要为哪个函数准备栈空间、预估初始大小（编译期分析函数局部变量和参数总大小）。
runtime.morestack 在 Go 1.3+ 中还起作用吗？
起作用，但角色变了。它不再用于“分配新栈段”，而是作为栈扩容的统一入口，最终调用 runtime.newstack 分配更大连续内存，并触发 runtime.copystack 拷贝数据。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Go 1.3 前：
morestack→ 分配新栈段 → 链入双向链表 - Go 1.3+：
morestack→newstack（malloc 更大内存）→copystack（逐字节复制）→stackfree（释放旧栈） - 关键差异：拷贝成本真实存在，且指针需重定位；但避免了 hot split 场景下反复 malloc/free 的锁竞争与 TLB miss
你在线上 profile 中看到大量 runtime.morestack 占比高，基本等于在告诉你：某处函数栈压得太满（比如深度递归、超大局部数组），正在高频触发扩容。
栈收缩为什么不是“自动”发生的？
连续栈确实支持收缩，但条件苛刻：当前栈使用量必须低于总容量的 1/4，且新栈大小不能小于 stackMin（Go 1.4+ 固定为 2KB）。这意味着大多数场景下，栈只扩不缩。
- 常见误判：以为 goroutine 退出后栈立即释放 → 实际上栈内存由 GC 管理，归属堆内存池，受
GOGC控制 - 后果：短生命周期 goroutine 大量创建/退出时，栈内存不会立刻归还 OS，表现为 RSS 持续上涨，pprof 显示
runtime.stackalloc分配量高 - 验证方式：
go tool pprof --alloc_space <binary> <heap.pprof>查看栈分配是否成为内存大户
真正影响内存水位的，从来不是“栈能不能缩”，而是“栈要不要缩”——Go 运行时宁可多占点内存，也不愿为省几 KB 频繁搬运和重定位指针。
连续栈不是银弹。它把“热分裂”的 CPU 抖动，换成了“扩容拷贝”的确定性开销；把“栈段管理复杂度”，换成了“GC 对栈内存的延迟回收”。理解这点，才能在写递归、传大结构体、启海量 goroutine 时，避开那些悄无声息吃掉你 CPU 和 RSS 的坑。
