metago是编译时代码生成框架，通过ast级建模生成类型安全、零开销的go代码，替代运行时反射在热路径上的性能损耗。
reflect 不是魔法，它是 Go 运行时暴露的一套类型与值的“快照接口”。它能用，但不该默认首选——尤其当你真正需要的是编译期确定性、类型安全和零开销时。
为什么 reflect.TypeOf 和 reflect.ValueOf 会拖慢热路径
每次调用 reflect.TypeOf 或 reflect.ValueOf，Go 都要从接口底层提取类型元数据指针、复制值内存块，并构造新的 reflect.Type / reflect.Value 实例。这不是简单查表，而是涉及 runtime 的深度 introspection。
- 对结构体字段遍历（如 JSON 序列化）：每访问一个字段都要走一次
v.Field(i)+v.Interface()，触发多次内存拷贝和类型断言 - 方法动态调用（
v.MethodByName("Foo").Call(...)）：绕过编译器内联和函数指针直接跳转，无法被 CPU 分支预测优化 - 反射值不可寻址时修改失败：比如传入
reflect.ValueOf(x)而非reflect.ValueOf(&x).Elem()，CanSet()返回 false，静默失效
go:generate 是更可控的元编程起点
go:generate 本身不生成代码，它只是告诉 go generate 命令该执行哪条 shell 命令。真正的生成逻辑由你写的工具（比如用 text/template 或 AST 操作）完成，输出的是标准 .go 文件，完全参与 go build 流程。
- 生成结果可被
go vet、gopls、staticcheck直接检查，错误在编辑器里就亮红 - 没有运行时开销：生成的
UnmarshalJSON方法就是手写函数，可内联、可优化 - 必须显式触发：
go generate ./...，避免“悄悄生成又忘记提交”的协作陷阱 - 注意路径问题：工具路径写成
../../tools/gen容易因工作目录不同而失败，建议用$(go env GOPATH)/bin/gen或 vendored 二进制
metaGo 的核心价值不在“生成”，而在“AST 级建模”
不同于字符串模板拼接，metaGo 让你用 Go 代码操作 Go 的抽象语法树（AST）。你不是在写“看起来像 Go 的字符串”，而是在构造 ast.StructType、ast.FuncDecl 这类真实节点。
- 字段名拼错？
ast.NewIdent("UsrName")会直接编译失败，而不是生成一个运行时报field not found的 struct - 想给每个生成的方法加 benchmark 标签？直接往
ast.FuncDecl.Decorations插入注释节点，而非正则替换源码 - 兼容性风险点：metaGo 依赖 Go SDK 的
go/ast和go/parser，升级 Go 版本后需同步验证 AST 节点结构是否变更（比如 Go 1.22 对ast.FieldList的内部字段调整）
反射和代码生成不是二选一，而是阶段分工
真正健壮的 Go 元编程方案，往往分层使用：
- 编译期：用
go:generate+ metaGo 生成强类型、无反射的胶水代码（如 ORM 的Scan方法、gRPC 的Validate实现） - 运行期：只在真正需要动态性的边界保留反射，比如框架的顶层路由分发器、通用配置绑定器
- 关键红线：绝不让反射穿透到业务核心循环里；所有高频调用路径上，
reflect.Value出现场景应为 0
go:generate，后期省下的不只是性能，还有调试时翻源码确认字段名是否拼对的耐心。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
