reflect不适合直接生成代码文件，因其仅能在运行时操作已有类型，无法创建新类型或写入磁盘；真正的代码生成需在编译前通过go:generate、ast解析等工具完成。
为什么 reflect 不适合直接生成代码文件
反射（reflect）在运行时只能读取或操作已有类型的结构，它无法创建新类型、新函数或写入磁盘文件。所谓“自动化代码生成”，实际是**在编译前通过工具读取源码/结构体定义，输出新的 .go 文件**——这和运行时反射无关。reflect 可能参与的是生成逻辑中的「类型分析」环节（比如解析 struct tag），但核心流程必须脱离运行时。
- 常见误用：在
main()里用reflect.TypeOf(&MyStruct{})然后试图拼字符串写文件 —— 这属于硬编码路径、无泛化能力、不可测试 - 真正可行路径：用
go:generate+ 自定义命令（如go run gen.go），配合ast包解析源码，或用reflect.StructTag辅助提取已有 struct 的元信息 - 性能影响：反射本身开销不大，但若在生成脚本中大量使用
reflect.Value.Interface()或嵌套遍历，会显著拖慢生成速度，尤其处理上百个 struct 时
用 reflect.StructTag 提取字段注解生成代码片段
这是反射在代码生成中最实用的场景：不生成完整文件，而是根据 struct tag 输出特定逻辑（如 JSON 序列化映射、数据库 column 名、gRPC 验证规则）。关键在于只读、不修改、不依赖运行时值。
-
struct必须是已编译可导入的（不能是生成脚本里临时定义的），否则reflect.TypeOf拿不到有效StructField - tag 解析推荐用标准库
structtag（go.dev/x/tools/go/structtag已归档，现用golang.org/x/tools/go/ast/inspector更稳妥，但简单场景reflect.StructTag.Get("json")足够） - 示例：从
type User struct { Name string `json:"name" db:"user_name"` }中提取dbtag 值，生成 SQL INSERT 字段列表
field, _ := t.FieldByName("Name")
dbTag := field.Tag.Get("db") // → "user_name"
if dbTag != "" {
fmt.Printf("INSERT INTO users (%s) VALUES (?)", dbTag)
}
生成代码时绕过反射，改用 ast 解析更可靠
如果你需要根据 struct 定义自动生成方法（如 Validate()、ToMap()），直接解析 Go 源码 AST 比反射更稳定、更可控。反射看到的是运行时类型，AST 看到的是原始声明，包括注释、行号、嵌套结构等。
- 用
parser.ParseFile()读取.go文件，用ast.Inspect()遍历*ast.TypeSpec找到目标 struct - 字段名、类型、tag 都能精准获取；还能判断是否导出、是否有重复字段、是否含内嵌 struct
- 避免反射陷阱：比如匿名字段提升后字段顺序错乱、interface{} 类型无法获知底层真实类型、未导出字段不可见
- 工具链建议：基于
golang.org/x/tools/go/loader（旧）或golang.org/x/tools/go/packages（新）加载包，再结合ast处理
go:generate + 命令行参数控制生成行为
把生成逻辑封装成可执行命令，用 //go:generate go run gen.go -type=User -output=user_gen.go 触发，比硬写反射循环灵活得多。
立即学习“go语言免费学习笔记（深入）”；
- 命令行参数决定作用范围：
-type指定 struct 名，-tags过滤条件（如只处理带jsontag 的字段），-template指定模板文件路径 - 生成器本身不 import 待处理的 struct 所在包（避免循环依赖），而是通过
packages.Load()动态加载 AST - 错误处理要具体：比如
struct not found in package、duplicate field name in tag，而不是 panic 或静默失败 - 生成的代码顶部必须加
// Code generated by gen.go; DO NOT EDIT.，否则go fmt和 linter 可能报错
