go反射慢是实打实的运行时开销：类型查询、字段线性搜索、方法调用校验等均耗时；应缓存reflect.type（用uintptr(unsafe.pointer(t))作key）、预计算字段偏移、用makefunc生成闭包、或通过go:generate提前生成代码。
Go 反射慢不是错觉，是实打实的运行时开销：每次 reflect.TypeOf 或 reflect.ValueOf 都要查类型表、分配临时结构体、触发接口转换；FieldByName 是线性搜索；Method.Call 要哈希查方法、校验参数、构建栈帧。热路径上它真能拖垮吞吐量。
缓存 reflect.Type 用 uintptr(unsafe.Pointer(t)) 当 key
同一类型的 reflect.Type 在整个程序生命周期内地址唯一且稳定，可安全缓存；但 reflect.Type 本身不可比较，不能直接作 map key。
- 正确方式：
uintptr(unsafe.Pointer(t))——零开销、无字符串拼接、不依赖包路径，encoding/json等标准库就这么干 - 错误方式：
map[reflect.Type]T（编译报错）、map[string]T（靠t.String()，对匿名 struct 失效，且有分配和哈希开销） - 别缓存
reflect.Value：它每次调用都新建，不可比较，缓存等于白干 - 避免在
init()里预热所有类型——你根本不知道哪些会被用到，纯属浪费内存
字段访问绕过 FieldByName，改用预计算 Offset + unsafe.Pointer
FieldByName 内部是遍历所有字段做字符串比对，100 字段就要比 100 次；而用偏移量直访是常数时间，接近原生访问。
- 初始化阶段一次性算出：
offset := unsafe.Offsetof(User{}.Name) - 后续读取：
*(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + offset)) - 前提：结构体字段顺序稳定、类型不变；加字段或改顺序会让 offset 失效
- 必须传指针（
*User），且确保对象不会被 GC 提前回收（命名类型安全，接口类型需警惕）
热路径彻底绕过 reflect.Value.Call，用 MakeFunc 生成闭包
reflect.Value.Call 开销主要不在“调用”本身，而在每次调用前的 receiver 校验、参数类型逐个转换、栈帧重建——单次 80–120 ns，比直接调用慢 50–100 倍。
- 签名固定时，用
reflect.MakeFunc在初始化阶段生成纯函数闭包，运行时零反射开销 - 示例：对
func(ctx context.Context) error方法，封装后后续调用就是普通函数调用 - 不能用于方法名动态变化的场景；必须确保参数类型和接收者类型绝对匹配，否则 runtime crash
- 别缓存
reflect.Value.Method(i).Call()的结果——它依赖具体实例，毫无复用价值
构建阶段生成专用代码，而非运行时反射
反射慢的本质是把编译期能确定的事拖到运行时做。go:generate 把这件事提前到构建阶段，为每个结构体生成专属的 MarshalJSON、UnmarshalJSON 或 CRUD 函数。
- ent 和 sqlc 的核心思路一致：读 AST 或 DB schema，生成类型固定、无反射的代码
- CI 中必须校验：
go generate && git diff --quiet || (echo "go:generate out of date" && exit 1) - 生成函数签名要与标准库一致（如接收
*T，返回error），便于无缝替换 - 慎用
unsafe偏移优化：快但危险，仅适用于明确性能瓶颈点的稳定结构体
最容易被忽略的是：缓存和偏移优化都建立在“结构体布局稳定”这个强假设上。字段重排、加字段、甚至启用 //go:notinheap 或 //go:build !no_unsafe，都会让预计算失效——这不是 bug，是权衡。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
