代码生成优于反射；reflect.valueof和fieldbyname因包装、分配、线性匹配成性能黑洞；go:generate移除运行时开销，提升类型安全与性能；缓存type有效，缓存value危险；关键在判断类型是否真不可预知。
高频、固定结构、性能敏感的场景，代码生成几乎总是优于反射；反射只在类型不可预知或泛型无法覆盖时才值得引入。
reflect.ValueOf 和 FieldByName 为什么是性能黑洞
每次调用 reflect.ValueOf 都要包装值、检查类型、可能触发堆分配；FieldByName 则在线性遍历所有导出字段做字符串匹配——字段越多越慢，且完全无法被编译器内联或优化。
- 一个 15 字段的 struct，
FieldByName("ID")比硬编码v.Field(0)慢 6–9 倍 - 循环中调用
reflect.ValueOf是典型误用：单次开销就达几十纳秒，累积后直接拉高 P99 延迟 - 嵌套 struct 或 slice 会让反射开销指数级上升，
ValidateWithReflect在含 2 层嵌套时 B/op 可能翻 3 倍
go:generate 生成代码的实际收益在哪
代码生成把运行时查表、字符串匹配、接口转换全移到编译前，换来的是零 runtime 开销、强类型安全和可调试性。
- Ent 或 sqlc 生成的查询方法，字段名写错会在
go build阶段报错，而非运行时 panic - 手写
ToJSON()或从 tag 生成的ScanRow()，执行耗时接近裸结构体赋值，ns/op 级别稳定 - 生成代码不增加 GC 压力——没有
reflect.Value对象逃逸，也没有临时 map/slice 频繁分配
缓存 reflect.Type 能省多少，但别碰 reflect.Value
缓存 reflect.Type 是有效手段，因为它是只读元数据指针；但缓存 reflect.Value 不仅无效，还危险。
-
sync.Map存reflect.Type → []reflect.StructField，首次解析后后续FieldByName可降为 O(1) 字符串查表 - 千万别把
reflect.ValueOf(x)结果存进全局变量或 map：它绑定具体值内存，可能阻止 GC，且并发不安全 - 字段索引映射应在初始化阶段完成，比如
map[string]int{"ID": 0, "Name": 1}，避免每次请求都重建
真正难的不是选反射还是生成，而是判断“类型是否真的不可预知”——很多所谓“动态”场景，其实只是没提前梳理结构契约。一旦类型集收敛，立刻切到生成；还在变、又没法定下来，才用反射，且必须配缓存和 IsValid/CanSet 检查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
