结论：应从写一个能跑的go:generate命令起步，而非先学代码生成器开发；只需掌握Go函数、文件读写和template.Execute即可生成可用代码，无需先啃AST或重型工具源码。
直接说结论：不要先学“代码生成器开发”，而是用它倒逼语言能力——从写一个能跑的 go:generate 命令开始，比啃 metaGo 或 protogen 源码更有效。
从 go:generate 注释入手，而不是从 AST 解析开始
很多初学者一上来就想写“能分析结构体字段并生成 CRUD”的工具，结果卡在 go/ast 的节点遍历和类型推导上。其实你根本不需要懂 AST 就能迈出第一步：只要会写 Go 函数、会读文件、会调用 template.Execute，就能生成真实可用的代码。
-
go:generate本质是 shell 命令触发器，不是框架——你写的main.go只要输出 .go 文件，它就成立 - 第一版生成器完全可以只依赖
text/template+os.Create，连go/types都不用导入 - 常见错误：把模板路径写成相对路径（如
"tpl/model.tpl"），但go generate是在包目录下执行的，实际路径应为./tpl/model.tpl或用runtime.GOROOT()定位 - 性能影响几乎为零——生成动作只在开发时手动触发，不参与构建流程
用真实结构体定义驱动模板，而非硬编码字段名
当你想为 type User struct { Name string `json:"name"` } 自动生成 String() 方法时，别在模板里写死 Name；而是让生成器读取这个结构体的 AST，提取字段名和 tag。这才是语言能力落地的关键点。
- 先写一个最小解析函数：
ast.ParseFile读源码 →ast.Inspect找ast.TypeSpec→ast.StructType提取字段 - 字段名要用
field.Names[0].Name，不是field.Name.String()——后者返回的是 AST 节点名，不是字段标识符 - tag 解析必须用
structtag.Parse，不能用字符串切分；否则遇到`json:"name,omitempty"`这种就会出错 - 容易踩的坑：没处理嵌套结构体或匿名字段，导致生成代码编译失败
避免过早引入 metaGo 或 code-generator 等重型工具
metaGo 的价值在于类型安全和可组合性，但它要求你理解 go/types.Config、types.Info、types.Object 这套类型系统抽象。对刚接触 Go 反射和 AST 的人来说，这相当于一边学骑车一边研究发动机原理。
立即学习“go语言免费学习笔记（深入）”；
- 官方
code-generator（如client-gen）专为 Kubernetes CRD 设计，输入必须是pkg/apis/.../v1/types.go这种固定布局，泛化成本高 - protogen 插件要求你实现
protogen.Plugin接口，且必须通过protoc管道通信——调试时 stderr 不会直接打印到终端，得加log.Printf并重定向 - 真正需要这些工具的信号只有一个：你已经用原生方式写了 3 个以上生成器，且每个都重复处理 import 行、package 声明、空行格式
把生成器当“语法练习器”，而不是一次性脚本
写一个能生成 HTTP handler 的模板，比写十个 “Hello World” 更能练语言细节：你需要处理 http.ResponseWriter 参数顺序、io.WriteString 错误检查、net/http 包导入是否冗余、甚至 func (h *Handler) ServeHTTP 方法接收者是指针还是值类型。
- 每次改模板，都强制自己运行
go fmt和go vet——生成的代码必须像手写的一样规范 - 故意在模板里漏写
err != nil判断，看编译报错信息，再反向补全逻辑，比读文档记得牢 - 把生成器命令写进
Makefile，而不是只靠go generate：这样你能自然学会$(shell go list -f '{{.Dir}}' ./...)这类 Makefile 与 Go 工具链的协作技巧
复杂点不在工具链选择，而在你愿不愿意让生成器暴露自己对 Go 类型系统、包管理、错误处理的真实掌握程度——它不会宽容任何含糊其辞的“大概知道”。
