预编译比运行时反射快一个数量级，因其将reflect.FieldByName等运行时线性查找和接口装箱移至go build阶段，生成代码仅含字段偏移、指针解引用和类型转换，避免查表、临时对象分配与GC，吞吐提升10–100倍。
为什么预编译比运行时反射快一个数量级
因为预编译把 reflect.FieldByName、reflect.MethodByName、reflect.Value.Call 这类运行时线性查找和接口装箱操作，全挪到 go build 阶段完成。生成的代码里没有 reflect 包调用，只有直白的字段偏移、指针解引用和类型转换——CPU 不用查表、不分配临时 reflect.Value、不触发 GC，实测吞吐提升 10–100 倍。
典型场景如 JSON 序列化、ORM 字段映射、gRPC 消息编解码，只要结构体类型集合固定（90% 的业务系统都满足），就该默认走预编译。
用 go:generate 生成字段访问器的最小可行方案
别写通用反射逻辑，直接为每个目标 struct 生成专用函数。例如给 User 生成 userToMap() 和 mapToUser()：
func userToMap(u *User) map[string]interface{} {
return map[string]interface{}{
"ID": u.ID,
"Name": u.Name,
"Age": u.Age,
}
}
关键点：
立即学习“go语言免费学习笔记（深入）”；
- 生成脚本用
go/types解析 AST，提取字段名、类型、json:tag，不依赖运行时reflect - 函数签名必须和标准库一致（比如接收
*T，返回error），才能无缝替换json.Unmarshal等调用点 - CI 中加校验：
go generate && git diff --quiet || (echo "generate out of date" && exit 1)
缓存 reflect.Type 是过渡手段，不是终点
如果你暂时没法上 go:generate，至少别让 reflect.TypeOf(x) 在热路径反复调用。但要注意：
- key 必须用
uintptr(unsafe.Pointer(t))，别用t.String()或t.PkgPath() + "." + t.Name()——前者对匿名 struct 失效，后者在模块多版本共存时会冲突 - 只缓存
reflect.Type和字段索引映射（map[string]int），别缓存reflect.Value：它每次都是新对象，不可比较，缓存无效 - 用普通
map+sync.RWMutex，别用sync.Map：读多写少场景下它的原子操作反而更慢
真正零开销的字段访问：用 unsafe.Offsetof 生成闭包
预编译的终极形态，是把字段内存偏移固化进函数体。例如：
var nameOffset = unsafe.Offsetof(User{}.Name)
func getName(u *User) string {
return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + nameOffset))
}
这种写法：
- 完全绕过
reflect，无接口转换、无 GC 分配、无字符串比对 - 前提是结构体字段顺序和类型稳定；加字段、改顺序、换 tag 都会让 offset 失效
- 必须传指针（
*User），且字段需 exported；//go:notinheap或go:build !race条件编译建议加上，否则 race detector 会报错
最容易被忽略的是：预热不能在 init() 里全量加载——你根本不知道哪些类型会被用到，纯属浪费内存。按需加载、懒构造才是正解。
