直接用 ast.walk 处理编译器级 ast 会出问题，因其单向、无返回值、不可中断，无法修改节点或提前退出；visit 中对 *ast.funcdecl.name 赋值无效，遇 main 函数只能靠 panic 或全局标志，破坏可重入性与安全性。
为什么直接用 ast.Walk 处理编译器级 AST 会出问题
因为 ast.Walk 是单向、无返回值、不可中断的遍历，它不让你修改节点，也不允许提前退出。你在 Visit 里对 *ast.FuncDecl 的 Name 字段赋值，实际不会生效；想在遇到第一个 main 函数时就停，只能靠 panic 或全局标志——后者破坏可重入性，前者不安全。
编译器前端真正需要的是：能边遍历边收集符号、报告错误、重写节点（比如宏展开）、并可控中断。这些 ast.Walk 全做不了。
-
ast.Walk适合纯统计类任务，比如数if语句个数 - 所有“改 AST”或“需上下文状态”的场景，都该换方案
- 别依赖闭包变量存状态——并发下易竞态，测试难隔离
ast.Inspect 怎么安全提取函数签名而不 panic
ast.Inspect 返回 bool 控制是否继续遍历，适合识别+缓存类分析，但不能改节点。提取函数签名时，关键不是“进参数列表再拆”，而是直接定位 *ast.FuncDecl 节点，从它的结构字段取值。
常见 panic 点：直接访问 FuncDecl.Recv.List[0].Type —— Recv 可能为 nil（普通函数非方法），List 也可能为空；Params 或 Results 字段本身可能为 nil，没判空就调 .List 必 panic。
- 先判
fn.Recv != nil && len(fn.Recv.List) > 0再取接收者 -
fn.Type.Params和fn.Type.Results都要先判非nil才访问.List - 接收者类型是
*ast.StarExpr表示指针接收者，但别直接类型断言转字符串——用go/format.Node格式化输出更稳 - 函数名是
fn.Name.Name，fn.Name本身可能为nil（如func() {}字面量），但*ast.FuncDecl的Name永不为nil
用 golang.org/x/tools/go/ast/astutil.Apply 替换节点的正确姿势
真要重写 AST（比如脱敏字符串、注入日志、展开泛型），必须用 astutil.Apply。它接受一个函数，对每个节点返回新节点或原节点，支持跳过子树、删除节点、替换节点——这才是编译器级操作的正路。
错误做法：在 ast.Inspect 回调里直接改 BasicLit.Value；正确做法是让 Apply 的函数返回新节点，并确保新节点结构合法。
- 替换字符串字面量时，只改
*ast.BasicLit.Value，但必须保留原始引号类型（"abc"→"***"，不能变成`***`） - 多行反引号字符串（
``）和含转义的字符串（"a\nb"）应跳过——它们几乎不是密码类敏感值，强行替换易引入语法错误 -
Apply的函数签名是func(*ast.File) *ast.File，返回值必须是新根节点，旧树不可变 - 别在
Apply中做 heavy I/O 或复杂计算——它在遍历路径上同步执行，拖慢整个流程
自定义 Visitor 结构体怎么管理跨节点状态
闭包变量够用？不够。静态分析常需记录当前函数名、作用域层级、是否在循环内等上下文。用结构体封装状态 + 方法，才是可测、可组合、线程安全的做法。
比如提取所有函数调用名，你要在进入 *ast.CallExpr 时判断左值是不是标识符，同时得知道当前是否在方法体内——这靠闭包很难清晰表达，且无法复用。
- Visitor 结构体字段存状态（如
Calls []string、InMethod bool） -
Visit方法必须返回ast.Visitor：返回自身继续遍历，返回nil终止当前分支 - 进函数时 push scope，出函数时 pop——
ast.Inspect不支持 enter/exit，得用ast.Walk配合自定义Walk函数，或改用golang.org/x/tools/go/ast/inspector - 别在
Visit里修改正在遍历的节点——AST 是只读的，改了也没用，还可能干扰后续判断
最易被忽略的是作用域边界：AST 本身不带作用域信息，ast.Inspect 也不提供父节点。需要自己维护栈，或者直接上 inspector——它内置类型匹配和作用域支持，但学习成本略高。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
