必须显式限制递归深度并改用显式栈：传depth参数校验、三步索引法建树、切片复制防共享、深度可控场景一律用[]*Node模拟调用栈。
func 写递归函数本身没门槛，但解决复杂问题时，不加约束的递归大概率会在 runtime 崩溃或性能失控——runtime: goroutine stack exceeds 1000000000-byte limit 这类错误不是警告，是直接终止进程，且 recover() 拦不住。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
必须显式传 depth 参数并校验
Go 不做任何递归深度检查，栈溢出是底层强制 kill，不走 panic 流程。所有可能被外部输入触发的递归（比如解析用户上传的嵌套 JSON、模板 include、菜单树展开），第一行就得拦：if depth > maxDepth { return errors.New("recursion too deep") }-
depth初始调用传0，每次递归传depth + 1 -
maxDepth不能硬写100；HTTP 头嵌套通常 ≤ 5 层，YAML!!include≤ 8 次，这些得写进常量注释或配置项 - 终止条件必须可达：用
if n 比 <code>if n == 0更安全，避免负数输入导致无限递归
树结构遍历别直接递归，先建索引再单次遍历
getTreeRecursive 这类纯递归构建组织架构树的写法，在真实数据中极易崩：
- 时间复杂度是
O(n²)：每查一个子节点都要全量扫描原始 slice，5000 条数据下耗时 >800ms - nil 指针 panic 风险高：若某
ParentID指向不存在的父节点，parent.Children = append(...)直接 panic - 栈深度不可控：组织架构常超 10 层，低配容器里
2KB初始栈很快撑爆
- 初始化
index := make(map[int]*Node)，键类型必须和Node.ID、Node.ParentID完全一致 - 第一遍遍历原始列表，把每个
&Node{ID: item.ID}存进index[item.ID] - 第二遍遍历，对每个
item查index[item.ParentID]，存在才追加到Children
切片传参时小心底层数组共享
递归中常用[]int 或 []*Node 传参，但 Go 的切片是引用类型，底层数组可能被多个递归层级复用：
- 归并排序里写成
mid := len(slice) / 2是错的——它判的是整个切片长度，不是当前子区间 - 正确写法是
if first >= last { return }+mid := first + (last - first) / 2 - 如果用
MergeSort(slice[first:last+1])，要确保不会因底层数组重叠引发数据竞争 - 更稳的做法是显式复制：
sub := make([]int, len(slice[first:last+1]))，再copy(sub, slice[first:last+1])
深度不可控场景一律改用显式栈
凡是用户可控嵌套深度的逻辑（如 JSON 解析、AST 遍历、路径展开），优先用[]*Node 模拟调用栈：
- 把“待处理节点”放进切片：
stack = append(stack, root) - 用
for len(stack) > 0驱动，每次pop := stack[len(stack)-1]; stack = stack[:len(stack)-1] - 子任务用
stack = append(stack, child)入栈 - 可随时插一句
if len(stack) > maxDepth { return errors.New("too deep") }，比函数参数更直观、更易调试 -
filepath.WalkDir就是这么干的——它用迭代+栈模拟，还支持context.Context中断
递归真正难的不是语法，而是你得在写第一行 func 之前就想清楚：这个调用链最深会到哪、谁控制它、崩了怎么收场。工程里多数“复杂问题”，其实靠索引 + 单次遍历 + 显式栈就解掉了，根本不需要让 runtime 去扛那堆栈帧。
