go代码重构必须用ast而非sed/grep，因后者会误改字符串、注释、遮蔽变量及跨行代码；ast仅匹配真实ast.callexpr节点，结合astutil.apply安全替换、go/printer格式化输出并补导入，复杂逻辑需手写遍历。
Go 语言里做自动化代码重构，绕不开 AST；不走 AST，基本等于在雷区里用文本编辑器跳踢踏舞——看着快，踩中一个就编译失败。
为什么不能用 sed / grep 替换 fmt.Println
纯文本替换在 Go 里几乎必然出错，不是“可能”，是“一定”会漏掉或误伤：
-
fmt.Println出现在字符串字面量里："fmt.Println(x)"，sed 会把它当调用处理 - 出现在注释中：
// fmt.Println("debug")，不该动但会被改 - 被局部变量遮蔽：
var fmt = &someFormatter{}，此时fmt.Println根本不是标准库调用 - 跨行写法：
fmt.\nPrintln("hello")，正则很难稳定匹配
AST 解析天然规避这些：它只匹配语法树上真实存在的 ast.CallExpr 节点，跟换行、缩进、注释、字符串内容完全无关。
用 astutil.Apply 安全替换函数调用
这是最常用也最稳妥的批量修改方式，核心是「遍历 + 条件判断 + 节点构造」：
- 先用
parser.ParseFile加载文件，拿到*ast.File - 写一个
pre函数，在里面检查是否为ast.CallExpr，再逐层判断Fun是否为ast.SelectorExpr且X.Name == "fmt"、Sel.Name == "Println" - 构造新节点：
&ast.SelectorExpr{X: &ast.Ident{Name: "log"}, Sel: &ast.Ident{Name: "Println"}} - 用
astutil.Apply(file, pre, nil)执行替换 - 别忘了补导入：
astutil.AddImport(fset, file, "log")，否则编译直接报错
示例中没做类型校验，实际关键重构后建议跑一次 go build 或 go vet 确认行为未变。
用 go/printer.Fprint 把 AST 写回源码
改完 AST 不等于改完代码，必须格式化输出，否则生成的代码可能缺空格、错缩进、丢注释：
- 输出目标用
*os.File或bytes.Buffer，别直接写到os.Stdout（除非只是调试） - 必须传入原始解析时用的
*token.FileSet，否则行号、注释位置全乱 - 调用
printer.Fprint(out, fset, file)，file是修改后的*ast.File - 写入后记得
out.Close()（如果是文件），或os.Rename(tmp, real)原子覆盖，避免中间状态被其他进程读到
漏掉 fset 或用错 fset，会导致注释漂移到奇怪位置，甚至丢失——这不是 bug，是 printer 没法还原位置信息的必然结果。
复杂重构必须自己写 AST 遍历逻辑
gopls 的 rename 和 extract function 只能解决通用操作；一旦需求带条件，比如：
- “只替换 test 文件里所有
db.Query调用，且参数含"SELECT"字符串字面量” - “把嵌套三层以上的
if err != nil提取为checkErr调用” - “给所有接收者为
*User的方法自动加if u == nil { panic(...) }”
就必须手写 ast.Inspect 或 astutil.Apply，并深入检查子节点结构。这时候 ast.Print 打印调试树、go/ast/astutil 的 Cut/Copy 工具会比想象中更有用。
真正容易被忽略的是错误传播路径：单文件处理出错可以跳过，但批量处理几百个文件时，没做 defer recover() 或没记录失败文件名，会让整个重构流程变成黑盒排查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
