直接用 go/parser 解析源码更可靠，因其严格遵循官方语法规范，能正确处理泛型、嵌套注释、行结束符及 //line 指令等边界情况，而手写 lexer+parser 易在泛型语法上出错。
为什么直接用 go/parser 解析源码比手写词法分析更可靠
Go 的标准库 go/parser 已经严格遵循官方语法规范，能正确处理泛型、嵌套注释、行结束符、甚至 //line 指令等边界情况。自己实现 lexer + parser 不仅耗时，还极易在 type T[P any] 或 func F[T any](x T) 这类泛型语法上出错。
实操建议：
- 始终用
parser.ParseFile配合token.NewFileSet()初始化，避免nil文件集导致 panic - 若需解析字符串而非文件，用
parser.ParseExpr或parser.ParseFile(fset, "", src, parser.AllErrors)，其中src是完整 Go 源码字符串 - 开启
parser.AllErrors标志，否则遇到第一个错误就停止，漏掉后续可修复问题
遍历 AST 时如何精准定位并修改特定节点类型
Go 的 AST 节点类型分散在 ast 包中（如 *ast.FuncDecl、*ast.StructType），不能靠字段名模糊匹配，必须用类型断言或 ast.Inspect 遍历。
常见错误：把 node.(*ast.Field) 写成 node.(*ast.FieldList)，导致 panic；或者在修改节点后忘记调用 fset.AddLine 更新位置信息，导致生成代码行号错乱。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 优先用
ast.Inspect而非ast.Walk，前者支持中途返回false提前退出，后者强制遍历全部 - 修改节点前先深拷贝：用
ast.Copy（需自行实现简易版）或重构为新建节点 + 复制关键字段，避免污染原始 AST - 识别函数签名时注意：
*ast.FuncDecl对应顶层函数，*ast.FuncLit才是闭包，二者Type字段结构不同
生成新代码时怎么保持格式与原文件一致
go/format.Node 只做基础缩进和换行，无法复用原文件的空格/Tab 混用风格、括号换行习惯（如 if ( 是否换行）、或注释对齐方式。直接 fmt.Sprintf 拼接易导致 go fmt 后代码变形。
实操建议：
- 用
printer.Config{Tabwidth: 8, Mode: printer.UseSpaces}控制空格缩进，但 Tabwidth 必须与源文件实际一致（可通过读取首行缩进推断） - 插入新字段或方法时，复用原
*ast.FieldList或*ast.FieldList的Opening/Closing位置，再用fset.Position获取对应行偏移，手动拼接 - 避免在
ast.Expr层面生成代码，改用ast.GenDecl+ast.TypeSpec等具体声明节点，让printer统一格式化
如何安全地将修改后的 AST 写回文件而不破坏原有内容
直接 os.WriteFile 全量覆盖会丢失 //go:build、BOM、UTF-8 BOM、文件末尾空行等元信息。更糟的是，如果生成过程 panic，原文件已被清空。
实操建议：
- 永远先写入临时文件（如
xxx_gen.tmp），校验无语法错误（go/parser再解析一遍）后再os.Rename - 保留原文件权限：
fi, _ := os.Stat(path); os.Chmod(tmpPath, fi.Mode()) - 若需增量更新（如只替换某段），用
fset.Position计算节点起止字节偏移，读取原文件内容，用bytes.ReplaceAll替换对应区间，而非全量重写
AST 工具最脆弱的环节不在解析，而在写回——位置信息错一位，整个文件就可能被删掉一半。务必在真实项目里先跑通一个最小 case，再加逻辑。
