go递归函数必须显式传入depth参数并校验，否则栈溢出直接崩溃且recover无效；应优先用切片模拟栈迭代替代深度不可控的递归。
Go 里写递归函数，不是不能写，而是必须带 depth 参数并校验——否则 runtime 一触发 runtime: goroutine stack exceeds 1GB limit 就直接崩溃，recover() 完全收不到。
递归函数必须显式传入 depth 参数并做边界检查
Go 没有内置递归深度检测，栈溢出是运行时强制终止，不经过 Go 的 panic 流程。所以靠 defer+recover 包裹递归调用毫无意义。
- 所有可能被用户输入触发的递归（如 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更安全，避免负数输入导致无限递归
归并排序等分治递归中 mid 计算错误会引发无限递归
常见错误是写成 mid := len(slice) / 2，而实际应基于当前区间计算：mid := first + (last - first) / 2。否则 MergeSort(slice, first, mid) 会反复调用相同参数，栈帧不断累积。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 错误写法：
if len(slice) —— 判的是整个切片长度，不是当前子区间 - 正确写法：
if first >= last { return }，配合mid := first + (last - first) / 2 - 若用切片传参（如
MergeSort(slice[first:last+1])），则需确保切片底层数组不被意外复用，避免数据竞争
优先用切片模拟栈替代递归
对深度不可控的场景（如解析用户上传的嵌套 JSON、AST 遍历），迭代比递归更可靠。Go 里用 []*Node 或 []state 模拟调用栈，配合 for 循环驱动。
- 把“递归参数”变成待处理任务，存进切片：
stack = append(stack, &Node{...}) - 每次
pop一个元素处理，子任务用append(stack, next)入栈 - 可随时加
if len(stack) > maxDepth实时限深，比函数参数更直观、更易调试 - 树遍历、表达式求值、路径展开都适用；
filepath.Walk就是典型安全封装，它内置软链接检测和错误传播，比手写递归稳得多
别碰 runtime/debug.SetMaxStack 和 -Xss 类参数
runtime/debug.SetMaxStack 控的是新 goroutine 的初始栈上限（默认 1GB），不是单次递归深度阈值。调大它只会让崩溃来得更晚、更难定位；调小它反而会让合法的大局部变量分配失败。
- Java 的
-Xss是线程栈大小，Go 没这概念 -
runtime.Stack返回的是当前已用栈大小，不是剩余空间，不能用来做安全判断 - goroutine 新建本身也有栈开销，避免在递归中起新 goroutine（比如
go f(x, depth+1)），问题会更隐蔽
最易被忽略的点：深度限制必须和终止条件协同生效——depth 校验只是守门员，但若终止条件本身不可达（比如逻辑分支漏判、参数未递减），再严的 depth 也拦不住栈溢出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
