go 连续栈扩容时，goroutine 的栈指针会自动更新吗？
不会自动更新——但 Go 运行时在每次函数调用前会检查栈空间，若不足则触发栈复制（stack copy），并把当前栈上所有活跃变量（包括局部指针）的地址重映射到新栈。这个过程对用户透明，但前提是这些指针必须是「栈上可追踪的」。
- 如果指针是
*int类型且指向栈上变量（比如&x），运行时能识别并修正； - 如果指针是通过
unsafe.pointer+ 偏移硬算出来的（比如unsafe.Add(unsafe.Pointer(&x), 8)），运行时无法识别，扩容后该地址失效； - 如果指针被存入全局 map 或 channel 等堆结构中，而原栈变量已随 goroutine 调度被复制，旧地址将悬空——这属于典型的「栈逃逸未发生却误用栈地址」问题。
runtime.stackGrow 不是你该直接调用的函数
Go 没有暴露栈扩容的控制接口。runtime.stackGrow 是内部函数，仅在 runtime 启动和少数特殊路径中由汇编触发，用户代码无法调用，也不应尝试绕过 GC 栈扫描逻辑去手动干预。
- 栈大小由编译器静态分析+逃逸分析决定：小对象优先留在栈，大对象或可能逃逸的会被分配到堆；
- 你看到的“栈扩容”其实是 runtime 在函数入口做的隐式检查：
morestack→newstack→ 复制旧栈 → 跳回原函数； - 频繁扩容（比如递归过深、局部数组过大）会导致性能抖动，此时应检查是否真需要那么大的栈帧，或改用切片+堆分配。
为什么 defer 和闭包捕获的变量在扩容后仍可用？
因为它们不是靠原始栈地址维持的——Go 编译器会把闭包捕获的变量提升为堆分配（除非确定生命周期短且不逃逸），而 defer 记录的是函数指针+参数值（或其副本），参数若为指针则指向的仍是有效内存（栈复制后已重映射）。
- 注意：如果 defer 参数是
&x，且x是栈变量，那它在扩容后依然有效，因为运行时重写了整个栈帧； - 但如果 defer 中用了
unsafe操作（比如把&x转成uintptr再传入），就失去追踪能力，扩容后该uintptr指向旧栈地址，读写会 panic 或静默损坏； - 典型错误示例：
go func() { println(uintptr(unsafe.Pointer(&x))) }()—— 这个uintptr不会被栈复制逻辑识别。
连续栈（Contiguous Stack）和老式分段栈的区别在哪？
Go 1.3 之后弃用了分段栈（segmented stack），改用连续栈：每次扩容不是拼接新段，而是分配一块更大的连续内存，把旧栈内容完整复制过去，再释放旧栈。这是为了消除“栈跨越段边界时的额外检查开销”。
立即学习“go语言免费学习笔记（深入）”；
- 连续栈让函数调用更可预测，但也意味着一次扩容成本更高（O(n) 复制）；
- 栈初始大小是 2KB（amd64），上限默认无硬限制，但受限于 OS 进程栈总限制（如 linux 默认 8MB per process）；
- 如果你在 CGO 调用中传入了 Go 栈上的地址（比如 C 函数里存了
&x），连续栈扩容后该地址失效——CGO 是唯一真正暴露栈地址不稳定的场景。
事情说清了就结束。真正要小心的不是扩容本身，而是任何把栈地址转成不可追踪形式的操作，尤其是混用 unsafe 和跨 goroutine / 跨语言边界的指针传递。