Go中防止无限递归爆栈的唯一有效手段是显式传入depth参数并校验，或改用切片模拟栈的迭代写法；recover、调大栈、尾递归、goroutine拆分均无效。
Go 里防止无限递归爆栈，唯一有效手段是：在递归函数入口显式加 depth 参数并校验，或直接改用切片模拟栈的迭代写法。靠 recover()、调大栈、尾递归优化、goroutine 拆分，全都不起作用。
递归函数必须带 depth 参数并立即校验
Go 的栈溢出（如 runtime: goroutine stack exceeds 1000000000-byte limit）发生在运行时保护层，早于 Go 的 panic 机制，recover() 完全捕获不到。所以防护不能靠“兜底”，只能靠“掐断”。
- 所有可能被用户输入、配置、嵌套结构触发的递归函数，第一行就得写：
if depth > maxDepth { return errors.New("recursion too deep") } -
depth初始调用传0，每次递归传depth + 1 -
maxDepth不能硬编码为100；HTTP 头嵌套建议 ≤5，YAMLinclude建议 ≤8，这些值要写进常量注释或配置项里 - 终止条件必须可达：比如用
if n 比 <code>if n == 0更防负数输入导致无限递归
分治类递归容易因区间计算错误绕过深度检查
归并排序、树区间遍历这类分治递归，常见错误不是漏写 depth 校验，而是子问题没真正缩小，导致 depth 一路涨到上限才报错，掩盖真实逻辑缺陷。
- 错误写法：
mid := len(slice) / 2—— 判的是整个切片长度，不是当前子区间，MergeSort(slice, first, mid)可能反复传入相同参数 - 正确写法：
mid := first + (last - first) / 2，配合终止条件if first >= last { return } - 若用切片传参（如
MergeSort(slice[first:last+1])），需确认底层数组未被复用，否则数据竞争可能让first/last逻辑失效
用 []*Node 模拟栈比测深度更可靠
当递归深度由外部输入决定（如解析用户上传的 JSON、AST 遍历、路径展开），仅靠 depth 参数只是“延缓崩溃”。真正稳的方式是去掉递归本身，用预分配容量的切片模拟调用栈。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 声明栈：
stack := make([]*Node, 0, 1024)，避免频繁扩容 - 入栈前判空：
if node != nil { stack = append(stack, node) }，防空指针死循环 - 入栈前实时限深：
if len(stack) > maxDepth { return errors.New("stack too deep") }，比函数参数更直观 - 图或带环结构中，“栈空”不等于“处理完”——必须维护
visited map[*Node]bool，否则重复入栈会导致内存持续上涨，现象和栈溢出高度相似但根源完全不同
哪些“常见解法”其实完全无效
这些方案在 Go 里要么语法不存在，要么根本不起作用，还可能误导排查方向。
-
defer+recover()包裹递归调用：实测无效，栈爆时recover()收不到任何信号 -
runtime/debug.SetMaxStack：只影响新 goroutine 的初始栈上限（默认 1GB），和单次递归深度无关；调大它只会让崩溃来得更晚、更难定位 - 尾递归写法（如
return dfs(node.Left)）：Go 编译器（截至 1.22）完全不支持尾调用优化（TCO），栈帧数不会少一个 - 用
go f()启动 goroutine 模拟迭代：把栈压力换成 goroutine 数量和调度开销，10 万次调用 ≈ 200MB 内存，且 channel 在 DFS 类强顺序场景下并发收益为零
最容易被忽略的点是：迭代改造时，终止逻辑和访问标记必须同步设计。光有 len(stack) == 0 不够，尤其在图或含软链接的路径场景中，忘了 visited 就会陷入“看似在跑、内存狂涨、查不出栈溢出错误”的假象。
