Go栈扩容由runtime自动完成，无需手动干预；频繁runtime.morestack表明深度递归或大局部变量导致栈热分裂；避免循环中声明大数组取地址，改用堆分配或sync.Pool；runtime.Stack在线上高危，应使用/debug/pprof/goroutine替代。
栈扩容不是你该手动干预的事
Go 的栈扩容完全由 runtime 自动完成，你写代码时不需要、也不应该去“触发”或“控制”它。所谓“做栈扩容”，其实是理解它怎么工作、怎么被意外触发、以及如何避免它成为性能瓶颈。
runtime.morestack 是性能红灯，不是调试工具
当你在 pprof 里看到大量 runtime.morestack 调用，说明你的 goroutine 正在频繁扩容——通常是深度递归、超大局部变量（比如 [8192]byte）或循环中反复声明大数组并取地址导致的。
- 常见错误现象：
panic: runtime error: stack overflow或 CPU 突增但无明显业务逻辑耗时 - 实操建议：用
go tool compile -S main.go | grep morestack快速筛查哪些函数可能触发扩容 - 避免写
for i := range xs { buf := [4096]byte{}; p := &buf }这类代码——每次迭代都压栈 + 逃逸，极易引发热分裂 - 若必须处理大缓冲区，改用
make([]byte, 4096)（底层数组在堆），或复用sync.Pool中的对象
runtime.Stack(buf, true) 在线上就是定时炸弹
想看所有 goroutine 栈？别直接调 runtime.Stack(buf, true)。它会暂停整个程序、遍历全部 goroutine、拼接字符串，1 万个 goroutine 下耗时可达 200ms，极易拖垮服务。
- 使用场景：仅限离线分析或紧急 debug；绝不能出现在 HTTP handler、RPC 方法或定时任务主路径中
- 安全替代方案：
/debug/pprof/goroutine?debug=2接口更轻量，支持采样且不阻塞调度器 - 如果非要用
runtime.Stack，务必：buf := make([]byte, 1（1MB 预分配）、加 <code>time.AfterFunc超时兜底、并限制每分钟最多调用 1 次 - 注意：
runtime.Stack(nil, false)返回的切片可能被 GC 回收，后续string()转换会乱码——永远用预分配的buf
栈大小和指针生命周期根本没关系
有人以为“把栈调大就能多存几个 *int”，这是典型误解。goroutine 栈大小（2KB 起、最大 1GB）只影响函数调用帧容量，不影响指针所指对象的内存位置或生命周期。
立即学习“go语言免费学习笔记（深入）”；
- 关键判断依据是逃逸分析：
go build -gcflags="-m" main.go看输出是否含moves to heap -
new(int)总在堆上；&v（v是局部变量）是否逃逸，取决于p是否被返回、传入 channel 或赋值给全局变量 - 跨 goroutine 传指针时，真正危险的不是栈大小，而是发送方函数已返回，而接收方还在 dereference —— 编译器不会报错，但运行时可能 panic
- 最稳妥做法：传值、用
sync.Pool管理临时对象、或明确用make分配堆内存并控制其生命周期
