Go递归栈溢出无法recover，必须显式传depth参数校验或改用预分配[]*Node迭代模拟；defer/recover和SetMaxStack均无效，核心是逻辑控制而非扩容。
会，而且一旦爆栈就直接崩溃，recover() 拦不住，runtime/debug.SetMaxStack 也改不了——这不是配置问题，是设计必须应对的硬限制。
递归函数入口必须带 depth 参数并校验
Go 运行时对栈溢出的处理是强制终止，不经过 Go 的 panic 流程，所以任何 defer + recover 包裹都无效。唯一能起作用的，是在递归调用第一行就做显式深度拦截。
- 初始调用传
0，每次递归传depth + 1 - 入口立即写：
if depth > maxDepth { return errors.New("recursion too deep") } -
maxDepth不能硬编码为100：HTTP 头嵌套建议 ≤5，YAMLinclude建议 ≤8，这些得写进常量注释或配置项里 - 终止条件必须可达：比如用
if n < 0 || n == 0比只写if n == 0更防负数输入导致无限递归
归并排序等分治递归中 mid 计算错误会绕过深度检查
看似加了 depth 校验，但若子区间划分逻辑错，递归不收敛，depth 就只是个计数器，实际栈帧还在疯涨。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
mid := len(slice) / 2—— 判的是整个切片长度，不是当前子区间 - 正确写法：
mid := first + (last - first) / 2，配合终止条件if first >= last { return } - 若用切片传参（如
MergeSort(slice[first:last+1])），要确认底层数组没被复用，否则数据竞争可能让first/last逻辑失效
用 []*Node 模拟栈比测深度更可靠
当深度不可控（比如解析用户上传的 JSON、遍历 AST、路径展开），靠 depth 参数只是“延缓崩溃”。真正稳的方式是去掉递归本身。
立即学习“go语言免费学习笔记（深入）”；
- 把递归参数转成任务对象，存进预分配容量的切片：
stack := make([]*Node, 0, 1024) - 每次
pop一个处理，子任务用append(stack, next)入栈 - 入栈前可实时检查：
if len(stack) > maxDepth { return errors.New("stack too deep") }，比函数参数更直观、更易调试 - 图或带环结构中，忘了维护
visited map[*Node]bool，会导致重复入栈、内存持续上涨，现象和栈溢出高度相似，但根源完全不同
最容易被忽略的点：迭代改造时，“栈空”不等于“处理完”；终止条件是否全覆盖、有没有被遮挡（比如 if n == 0 前面还有未校验的指针解引用），这些细节比深度阈值本身更容易引发真实崩溃。
