Go 协程栈溢出时 panic 信息长什么样
遇到 runtime: goroutine stack exceeds 1g limit 或 fatal error: stack overflow 就是协程栈爆了。这不是传统 C 的栈溢出信号，而是 Go 运行时主动检测到当前 goroutine 的栈空间（默认上限 1GB）被耗尽后抛出的 panic。注意：它不一定是递归太深，也可能是大量局部变量 + 多层调用累积占满栈。
- 典型触发场景：
func f() { f() }无限递归、深度 JSON 解析嵌套结构、AST 遍历未设深度限制 - panic 发生在当前 goroutine 内，不会波及主线程或其他 goroutine
- 栈大小不是固定值——Go 会动态扩容，但每次扩容需分配新内存并拷贝旧栈，到接近 1GB 时拒绝再扩
如何查出哪个 goroutine 在吃栈
光看 panic 不够，得定位具体函数调用链。关键靠 runtime.Stack 或 panic 时自动打印的 goroutine dump。
- 启动时加
GODEBUG=gctrace=1只管 GC，不管栈；真正有用的是GOTRACEBACK=2（或设为all），能让 panic 打印所有 goroutine 的栈帧 - 在 panic 前主动捕获：用
recover()+debug.PrintStack()，但仅对当前 goroutine 有效 - 更准的办法：用
pprof抓 goroutine profile，go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查活跃栈深度
递归函数怎么改才不爆栈
Go 不支持尾递归优化，所以不能靠“编译器帮你转成循环”。必须手动重构，核心思路是把调用栈从 runtime 栈挪到堆上。
- 用显式栈（
[]interface{}或自定义 struct）模拟调用过程，比如遍历树时 push/pop 节点而非traverse(node.Left) - 把深层递归拆成 channel + worker 模式：每个子任务起新 goroutine，但要控制并发数，否则内存爆炸
- 对已知深度上限的场景，可用
runtime.GOMAXPROCS(1)配合runtime/debug.SetMaxStack（⚠️仅测试用，生产禁用）观察临界点
示例改造片段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
func walkRecursive(n *Node) {
if n == nil {
return
}
walkRecursive(n.Left)
process(n)
walkRecursive(n.Right)
}
// → 改为
func walkIterative(root *Node) {
stack := []*Node{root}
for len(stack) > 0 {
n := stack[len(stack)-1]
stack = stack[:len(stack)-1]
if n == nil {
continue
}
stack = append(stack, n.Right, n.Left) // 注意顺序
process(n)
}
}
goroutine 栈大小能调吗？该不该调
不能全局调，也不能在启动后改单个 goroutine 的初始栈大小。Go 1.19+ 默认初始栈是 2KB，后续按需增长，上限硬编码为 1GB —— 这个上限连 unsafe 都绕不过。
-
runtime.stackSize是内部常量，未导出，不可修改 - 有人试过用
CGO调pthread_attr_setstacksize，但 Go 的 M:N 调度模型让这种操作无效且危险 - 真正可控的是 goroutine 创建方式：
go func() { ... }()无法指定栈，但你可以用sync.Pool复用大对象，减少栈上分配压力
最常被忽略的一点：栈溢出往往不是因为递归层数多，而是每层压了太多大变量（比如大数组、闭包捕获大结构体）。检查 go tool compile -S 输出里的栈分配量，比盲目调参管用得多。
