recover 对 parser/ast 遍历无效，因其不触发 panic：parsefile 遇错返回 error，ast.walk 本身不 panic；仅当用户代码误用类型断言或解引用 nil 时才可能 panic，此时 recover 可捕获但属使用错误。
recover 无法拦截语法树遍历过程中的 panic——因为语法树遍历（如 go/parser 解析源码、go/ast 遍历节点）本身不运行用户代码，也不会触发 Go 运行时的 panic 机制；它只在遇到非法输入（如严重语法错误）时返回 error，而不是 panic。
为什么 recover 对 parser/ast 遍历完全无效
Go 的 recover 只能捕获当前 goroutine 中由 panic 显式触发（或运行时崩溃如 nil 指针解引用）的异常，且必须在 defer 函数中调用。而：
-
go/parser.ParseFile在语法错误时返回*parser.ErrorList或nil+error，从不 panic -
ast.Walk或自定义ast.Visitor遍历时，若你自己的访问逻辑里写了panic（比如误判节点类型后强制断言），那recover才可能生效——但这是你代码的问题，不是“语法树遍历过程”本身的 panic - AST 节点字段（如
Ident.Name）是普通 struct 字段，访问它们不会 panic；只有你手动对 nil 接口/指针做解引用（如n.(*ast.CallExpr).Fun而n实际是*ast.Ident）才会 panic，这属于类型断言失败，可 recover，但属于使用错误，非遍历机制所致
真正该检查和防御的位置：Parse 和 Type Assert
常见崩溃点其实就两个地方，都不靠 recover，而靠显式判断：
- 解析阶段：用
if err != nil检查parser.ParseFile返回值，不要忽略err—— 它包含所有语法错误位置和描述 - 遍历阶段：避免盲目类型断言。改用
if ce, ok := n.(*ast.CallExpr); ok { ... }，而不是直接ce := n.(*ast.CallExpr) - 访问子节点前先判空：例如
if f := expr.Fun; f != nil { ... }，因为 AST 中很多字段允许为 nil（如ast.ReturnStmt.Results可为 nil 切片）
什么情况下 recover 才值得加？仅限你主动 panic 的场景
如果你在 Visitor 的 Visit 方法里主动 panic("unsupported node") 来中断遍历，那可以在外层 defer+recover 捕获并转成错误：
func walkSafely(fset *token.FileSet, node ast.Node) error {
var result error
defer func() {
if r := recover(); r != nil {
result = fmt.Errorf("walk panic: %v", r)
}
}()
ast.Walk(&myVisitor{}, node)
return result
}
但这属于「控制流替代错误返回」的非常规做法，不推荐。标准做法是让 Visit 返回 ast.Visitor（即继续遍历）或 nil（停止），并通过闭包变量收集错误。
真正容易被忽略的是：AST 遍历本身健壮，出问题几乎总是因为你没检查 nil、没处理 error、或用了不安全的类型断言——这些地方加 recover 不是补救，而是掩盖设计缺陷。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
