Go中DFS递归易panic，因goroutine初始栈仅2KB、上限约1GB，超千层即触发stack exceeds limit；须用显式栈迭代替代，禁用尾递归，加深度校验与访问标记。
为什么 DFS 递归在 Go 里容易 panic
因为 Go 的 goroutine 初始栈只有 2KB，且按需扩展有上限（约 1GB），深度超过千层就触发 runtime: goroutine stack exceeds 1000000000-byte limit。这不是代码写错，而是运行时主动终止——它不希望你靠堆栈硬扛深度。
常见爆栈场景：不平衡二叉树遍历、嵌套 JSON/YAML 解析、N 皇后回溯。尤其当输入可控（如 API 接收用户提交的嵌套结构）时，恶意构造 2000 层嵌套就能让服务 panic。
- 递归调用每次压栈，深度 = 栈帧数，和数据规模线性相关
-
defer+recover拦不住这种 panic，它发生在 runtime 层，Go 的 panic 机制根本没机会介入 - 别试
ulimit -s或GODEBUG=stackguard=，这些对 goroutine 栈无效
尾递归写法完全没用
Go 编译器（截至 1.22）**不支持尾递归优化（TCO）**，哪怕函数末尾只调自己，比如 return dfs(node.Left)，栈帧照样增长。这不是写法问题，是明确的编译器限制。
实测 tailFactorial(100000, 1) 仍会栈溢出；某些情况下，尾调用甚至比普通递归更慢（多一次函数地址跳转）。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 别信“改成尾递归就能省栈”这类误导，Go 里没有
@tailrec或类似修饰符 - 用
goroutine+channel模拟尾调用？只会把栈压力转成 goroutine 数量，10 万次调用 ≈ 200MB 内存，还引入调度开销和竞态风险 - 真正省栈的唯一路径是手动展开 + 状态机化，比如把“当前处理左/右/回退”编码进 struct 字段
用 slice 模拟栈实现迭代 DFS
把隐式调用栈搬到堆上，用 []*Node 控制内存节奏，既规避栈限制，又便于加深度检查。
关键不是“去掉递归”，而是把“谁保存状态”从 runtime 切到你自己手上。原始递归 dfs(node.Left) 是压栈，迭代版是 stack = append(stack, node.Left)。
- 用指针
*Node入栈，避免复制大结构体；若节点含slice或map，更要小心逃逸分析 - 预估最大深度，用
make([]*Node, 0, 1024)初始化切片容量，减少扩容次数 - 图遍历必须加访问标记，否则仅靠
len(stack) == 0会死循环——这是最容易忽略的坑
深度防护不能只靠迭代
即使改用迭代，也要防极端输入。比如解析 YAML 模板 include 嵌套，业务上最多允许 8 层，那就得在入栈前校验：if len(stack) > maxDepth { return errors.New("max include depth exceeded") }。
- 最大深度值不能硬编码为 100，要结合场景：HTTP 头嵌套 ≤5 层，AST 遍历 ≤200 层，这些应写进配置或常量注释
- 测试必须覆盖超深嵌套输入，本地跑一次没问题 ≠ 上线安全
- 旧代码不敢动？可在递归入口加
depth参数守卫，像处理context.Context一样严肃对待
最易忽略的是：迭代改造时，“递归终止条件”平移成“栈空判断”只是第一步，还得确保每个节点入栈前已判重——否则图遍历直接无限循环。
