Go 的 ast 包不负责语法分析，需用 go/parser 解析源码字符串为 *ast.File；遍历修改应优先用 ast.Inspect 或 astutil.Apply，避免手动赋值或误用 ast.Walk。
Go 的 ast 包本身不用于“创建语法分析程序”，它只负责处理已解析出的抽象语法树（AST）；真正做语法分析（即词法 + 语法解析）的是 go/parser 和 go/scanner。直接用 ast 无法从源码字符串得到 AST——你得先调用 parser.ParseFile 或类似函数。
怎么从 Go 源码字符串拿到 *ast.File
常见错误是试图绕过 parser 直接构造 *ast.File，这不可行，因为 AST 节点间有严格位置、作用域、类型关联，手动拼凑极易崩溃或被 ast.Inspect 忽略。
- 必须用
parser.ParseFile（读文件）或parser.ParseExpr/parser.ParseStmt（单表达式/语句） - 若输入是字符串而非文件，需用
token.NewFileSet()并传入src参数：fset := token.NewFileSet() f, err := parser.ParseFile(fset, "", "package main; func f() { return 42 }", 0) - 忽略
fset会导致所有节点Pos为 0，后续定位、重写、格式化全失效
如何安全遍历和修改 AST 节点
ast.Inspect 是最常用方式，但它不支持在遍历中直接修改子节点指针——返回 false 可跳过子树，但不能替换当前节点。真要改结构，得用 ast.Copy + 递归重写，或更稳妥的 golang.org/x/tools/go/ast/astutil。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别在
ast.Inspect回调里赋值如n.Name = "newName"——部分字段是只读的，或需要同步更新Obj字段 - 修改函数体？用
astutil.Apply更安全，它自动处理父指针和位置信息：astutil.Apply(f, nil, func(c *astutil.Cursor) bool { if call, ok := c.Node().(*ast.CallExpr); ok && ast.IsIdent(call.Fun, "log.Println") { c.Replace(&ast.CallExpr{Fun: ast.NewIdent("fmt.Println")}) } return true }) - 所有修改后，务必用
format.Node验证输出是否符合预期，否则可能生成非法 Go 代码
为什么不能用 ast.Walk 替代 ast.Inspect
ast.Walk 是底层遍历器，暴露的是 ast.Visitor 接口，它要求你显式控制子节点访问顺序，且不提供“跳过子树”这种便捷能力。绝大多数场景下，ast.Inspect 更简洁、不易出错。
立即学习“go语言免费学习笔记（深入）”；
-
ast.Walk的Visit方法必须返回ast.Visitor，返回nil表示停止遍历整个树——没法只跳过某个分支 - 如果你需要精确控制访问深度（比如只进函数体三层），才考虑
ast.Walk；日常分析、日志、简单重写，ast.Inspect足够 - 注意：两者都不保证节点访问顺序稳定（例如
FuncDecl的Body可能在Type之前或之后被访问），别依赖顺序做状态累积
真正难的不是遍历 AST，而是理解每个节点字段的语义约束——比如 *ast.FieldList 的 List 为空时不能设为 nil，*ast.Ident 的 Obj 在未经过 go/types 检查前是 nil。这些细节不报错，但会导致后续工具链（如 gofmt、go vet）行为异常。
