直接修改ast.callexpr易出错，因其不维护token位置和注释归属，导致格式崩坏；应仅用go/ast做语义判断，文本替换交由gofumpt/go/format处理。
为什么直接改 ast.CallExpr 容易出错
很多人想用 go/ast 手动替换函数调用，比如把 log.Printf 换成 zap.Sugar().Infof。但实际操作中常遇到：调用参数顺序错乱、括号嵌套被破坏、go/format 输出后缩进崩坏、甚至整个文件解析失败。根本原因是 ast.CallExpr 只描述语法结构，不维护 token 位置和注释归属——你改了 Fun 字段，但没同步更新它前面的注释、空格或换行符，go/printer 就会按默认规则“猜”怎么格式化，结果不可控。
用 gofumpt + go/ast 配合做安全替换
真正可落地的做法是：只用 go/ast 做语义判断（比如识别目标调用、提取参数），不碰 ast.Node 的字段赋值；所有文本级修改交给 gofumpt 或 go/format 保证格式正确。关键步骤如下：
- 遍历
*ast.File，在Visit中定位到*ast.CallExpr，检查CallExpr.Fun是否为*ast.SelectorExpr且名字匹配（如log.Printf） - 用
ast.Inspect提取参数表达式，不修改 AST 结构，只收集args列表 - 调用
token.FileSet.Position获取原调用起止位置，用fileset.File.Line精确切出源码片段 - 拼接新调用字符串（如
zap.Sugar().Infof(%s, %s)），用bytes.ReplaceAll替换原片段 —— 这步绕过 AST 修改，避免格式错乱 - 最后用
gofumpt.Format重排整文件，确保缩进、空格、换行符合 Go 社区规范
go/ast 替换时必须避开的三个坑
即使你坚持走纯 AST 路线，以下三点不处理，生成的代码大概率编译失败或行为异常：
- 别直接赋值
call.Fun = &ast.SelectorExpr{...}：这会丢失原Fun节点的token.Pos，导致后续go/printer把新节点塞到文件开头 - 参数列表不能用
append直接塞新*ast.BasicLit：要先调用ast.Copy复制原参数节点，再修改其Value，否则引用共享会导致多个调用互相污染 - 别忽略
call.Ellipsis字段：如果原调用是fmt.Printf("a", args...)，漏掉call.Ellipsis的复制，生成的代码会丢掉...，变成fmt.Printf("a", args)，语义全变
更推荐的替代方案：用 gofind + goreplace
对大多数包内函数调用重构场景，硬啃 go/ast 是高成本低收益。实际项目中，90% 的批量替换可用更轻量的方式完成：
- 用
gofind 'log\.Printf(.*?)"' -in ./internal/快速确认匹配范围，避免误伤测试文件或 vendor - 用
goreplace 'log\.Printf\((.*?)\)' 'zap.Sugar().Infof($1)' -in ./internal/直接文本替换，支持正则捕获组，保留原有参数结构 - 替换后跑
go vet和golint，重点看是否引入未声明变量（比如zap包没 import） - 最后执行
go fmt ./...统一格式 —— 这比手写 AST 遍历快 5 倍，且结果确定可控
真正需要 go/ast 的，只有那些依赖上下文语义的场景：比如只替换某个 struct 方法内的 fmt.Println，而跳过全局函数里的同名调用。这种复杂度下，才值得投入精力写完整 AST 分析器。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
