直接修改 ast.Node 不生效，因 Go 的 ast 包采用不可变语义；需用 astutil.Apply 配合 pre/post 回调实现安全替换，手动修改字段或仅复制节点而不更新父引用均无效。
为什么直接修改 ast.Node 通常不生效
Go 的 ast 包设计为不可变（immutable）语义：你拿到的 *ast.CallExpr 或 *ast.FuncDecl 是解析后生成的只读快照，原地修改字段（比如改 Fun 或 Body）不会触发重写逻辑。真正起作用的是 ast.Inspect 和 ast.Copy 配合 astutil.Apply —— 后者才是专为“转换”设计的入口。
常见错误现象：ast.Inspect 中对节点字段赋值后，调用 printer.Fprint 输出仍是原始代码；或用 ast.Copy 复制后改了副本，但没把副本挂回父节点的对应字段上。
-
ast.Inspect只读遍历，返回值被忽略，无法替换节点 -
ast.Copy返回新节点，但父节点引用未更新 → 修改丢失 - 手动递归遍历需自己处理所有节点类型分支，极易漏掉
*ast.GenDecl、*ast.TypeSpec等边缘情况
用 astutil.Apply 做安全替换的三步法
astutil.Apply 是标准库中唯一支持“边遍历边替换”的工具，它通过两个回调函数控制流程：一个决定是否进入子树（pre），一个决定是否替换当前节点（post）。关键在于：只有 post 返回非 nil 的新节点，才会真正替换原位置。
使用场景：批量重命名函数调用、插入日志语句、删除特定 if 分支、将 fmt.Printf 替换为 log.Printf。
-
pre函数返回astutil.VisitNode继续遍历，或astutil.SkipNode跳过子树（如跳过注释或字符串字面量） -
post函数接收原节点和子节点处理结果，必须显式返回替换后的节点（或原节点） - 若
post返回nil，该节点被删除；返回新节点则完成替换；返回原节点则保持不变
newRoot, _ := astutil.Apply(fset, root, func(cursor *astutil.Cursor) bool {
// pre: 进入前判断
return true
}, func(cursor *astutil.Cursor) bool {
// post: 替换逻辑
if call, ok := cursor.Node().(*ast.CallExpr); ok {
if ident, ok := call.Fun.(*ast.Ident); ok && ident.Name == "fmt.Printf" {
// 构造 log.Printf 调用
newCall := &ast.CallExpr{
Fun: &ast.SelectorExpr{
X: &ast.Ident{Name: "log"},
Sel: &ast.Ident{Name: "Printf"},
},
Args: call.Args,
}
cursor.Replace(newCall) // 关键：触发替换
return false // 不再遍历新节点内部
}
}
return true
})
astutil.Apply 容易踩的坑：作用域与副作用
在 post 回调里构造新节点时，别直接复用原节点的字段指针（比如 call.Args），因为 Args 是 []ast.Expr，其元素可能已被 astutil.Apply 递归处理过 —— 如果你在 pre 里做了修改，post 拿到的 call.Args 已是新版本。更稳妥的方式是用 cursor.Children() 获取已处理后的子节点，或手动 deep-copy 表达式。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
性能影响：每次 cursor.Replace() 都会重建父节点的字段切片（如 Stmts、Args），频繁替换小节点（如 *ast.Ident）开销不大，但替换整个 *ast.BlockStmt 会触发大量内存分配。
- 不要在
pre里修改节点字段，那只是临时快照 - 避免在
post中调用ast.Print或其他依赖fset的调试操作 ——fset未同步更新 Pos 信息，可能 panic - 如果要保留原节点位置信息（如用于 error reporting），记得把
call.Pos()和call.End()显式赋给新节点
转换后必须做类型检查和格式化
AST 转换不保证语义正确性。比如把 len(s) 替换成 cap(s)，AST 层合法，但运行时可能 panic。所以转换后应走一遍 types.Check，或至少用 go/format 格式化输出验证结构合法性。
常见错误现象：转换后 go build 报 syntax error: unexpected semicolon or newline —— 往往是因为漏了某个 ast.FieldList 的 Closing 字段，或 ast.IfStmt 的 Else 指针为 nil 但语法要求存在 else 子句。
- 用
go/parser.ParseFile加parser.ParseComments选项确保注释也被解析，否则astutil.Apply可能跳过带注释的节点 - 转换后调用
format.Node输出到bytes.Buffer，再用go/parser.ParseFile二次解析，可快速捕获语法断裂 - 若涉及包级声明变更（如加 import），记得同步更新
*ast.File.Imports并调用ast.SortImports
实际做复杂转换时，最麻烦的不是节点构造，而是边界 case：嵌套的 func() { }()、带标签的 for 循环、type T struct{ f int "json:\"f\"" } 中的 struct tag 字符串 —— 这些地方的 AST 结构和位置信息稍有偏差，生成的代码就无法编译。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
