recover必须在每层递归的defer中显式声明，因各递归调用为独立栈帧；仅在外层入口写defer recover只能捕获本层panic，无法捕获深层递归中的panic（如越界访问）。
recover必须在每层递归的defer中显式声明
递归函数里发生的panic不会被外层函数的defer捕获，因为每个递归调用都是独立的函数栈帧。你不能只在入口函数写一个defer func() { recover() }()就指望它兜住所有深层panic——那只会捕获最外层函数本身的panic，对第5层递归里越界的slice[i]完全无效。
常见错误是把recover写在递归入口，但panic发生在深层调用里：
func badRecursive(n int) {
defer func() { recover() }() // 这个recover只管本层，不管递归子调用
if n <= 0 {
panic("base case panic")
}
badRecursive(n - 1) // 子调用panic后，本层recover不触发
}正确做法是：每一层递归都带自己的defer + recover逻辑：
- 要么在递归函数体开头就注册
defer func() { if r := recover(); r != nil { /* 处理 */ } }() - 要么把递归逻辑包进闭包，在闭包内统一加defer（更易读）
- 注意：recover后该层函数立即return，不会继续向下递归
recover后无法“继续递归”，只能降级或返回错误值
recover不是让程序跳回panic发生点重试，它只是让当前函数安全退出。你在第3层递归里recover到panic后，第3层函数就结束了，第2层的badRecursive(n-1)调用已经返回，不会自动再试一次或跳过出错分支。
立即学习“go语言免费学习笔记（深入）”；
所以实际处理逻辑得靠显式判断，而不是依赖recover“恢复执行”：
- 不要写：
recover(); continue // 不存在的语法 - 应该写：
if r := recover(); r != nil { return fmt.Errorf("failed at depth %d: %v", depth, r) } - 若需降级（比如从深度优先切到广度优先），必须在recover分支里手动改逻辑，不能靠“恢复原流程”
- 已发生的副作用（如已写入map、已发channel消息）无法回滚，recover不提供事务语义
避免在递归中滥用panic，优先用error返回
递归场景下，绝大多数异常其实是可预期的边界条件：索引越界、空节点访问、深度超限。这些更适合用error返回，而不是触发panic再recover——前者清晰、可控、可测试；后者绕弯、难调试、容易漏捕获。
比如树遍历：
- 错：遇到nil节点就
panic("nil node")，再靠recover兜底 - 对：函数签名设为
func traverse(node *TreeNode) error，遇到nil直接return errors.New("nil node at depth X") - 只有真正不可恢复的情况才用panic，例如：递归栈深度突破Go runtime限制（极罕见）、内存分配失败（几乎不可能）
滥用panic会掩盖真实控制流，让递归终止条件变得隐晦，且recover嵌套过深时极易漏掉某一层的defer。
goroutine + 递归 + recover的组合要格外小心
如果递归调用是在新goroutine里发起的（比如分治任务拆成多个go routine），那么recover完全失效——因为recover只对**当前goroutine**的panic有效。你在主goroutine defer里写的recover，对子goroutine里panic毫无反应。
典型陷阱：
-
go recursiveFunc(n-1)中发生panic → 主goroutine不受影响，但子goroutine直接崩溃并打印stack trace - 想捕获？必须在子goroutine内部自己写
defer func(){ recover() }() - 更稳妥的做法：根本不在goroutine里做深度递归，改用迭代+显式栈，或用worker pool控制并发粒度
递归本身已增加理解成本，再叠上goroutine和recover，出问题时很难定位是哪一层、哪个goroutine崩的——这时候该反思是不是架构设计过重了。
