应避免运行时反射，优先用go:generate在构建期生成零反射代码，如JSON序列化、SQL操作等；接口抽象和方法提升替代字段反射访问；缓存reflect.Method而非reflect.Value.Call。
能不用反射就别用——这不是保守，而是 Go 编译器明确告诉你的事实：反射调用比原生调用慢 10–100 倍，且无法通过“优化反射写法”抹平差距。真正要极致性能，就得把反射逻辑从运行时搬到构建期或编译期。
go:generate 生成零反射的结构体操作函数
常见场景如 JSON 序列化、HTTP 参数绑定、DB 插入拼字段，本质都是对已知结构体做固定模式转换。这类逻辑完全可在构建时生成纯 Go 代码。
- 不要写
json.Marshal+reflect.ValueOf遍历字段；改用go:generate为每个struct生成专属的MarshalJSON函数 - 避免手写 tag 解析（如
json:"name,omitempty"），用github.com/iancoleman/strcase处理命名转换，模板里直接展开字段赋值 - CI 必须校验：
go generate后跑git diff --quiet，失败则阻断发布——否则字段增删后生成代码不同步，直接 panic 或丢数据 - 生成函数签名要和标准库一致（如接收
*T，返回error），方便后续无缝替换
ent 或 sqlc 替代手写 ORM 反射层
自己用 reflect.StructField 拼 SQL 是典型的热路径滥用反射。每条 INSERT 都重复解析结构体、提取 tag、构建参数切片，开销肉眼可见。
-
ent要求你定义ent/schema，生成的是类型固定、零反射的 CRUD 方法，如client.User.Create().SetAge(25).Save(ctx) -
sqlc从 SQL 文件反推 Go 类型，生成的db.Queries.CreateUser(ctx, arg)参数直接绑定，不经过interface{}和反射拆包 - 别在
ent生成代码外再包一层“泛型 repository”——那会重新引入反射、接口逃逸和 GC 分配
接口抽象 + 方法提升替代字段反射访问
当设计通用接口（如 Vehicle）并期望所有实现类型共享嵌入字段（如 Engine）时，直接通过接口访问字段会失败。此时用 reflect.ValueOf(v).Elem().FieldByName("Power") 虽能工作，但 pprof 显示 CPU 占用激增。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 推荐方案：将字段访问逻辑抽象为接口方法，并利用嵌入自动提升，例如
func (e Engine) GetPower() float64 { return e.Power }，所有嵌入Engine的 struct 自动获得该方法 - 优势是零反射开销、强类型安全、无重复实现、易于扩展
- 若无法修改接口（如第三方库约束），可用类型断言或
switch v := interface{}.(type)作为折中，但需注意类型覆盖完整性
缓存 reflect.Method 而非 reflect.Value.Call
reflect.Value.Call 单次开销 100–500ns，高频场景下直接拖垮吞吐。真正瓶颈不在“调用”本身，而在每次调用前的 receiver 可寻址性校验和参数类型逐个转换。
- 必须确保 receiver 是指针：
reflect.ValueOf(&v)，而非reflect.ValueOf(v) -
reflect.Method可以缓存（它是只读、全局单例），正确方式是cache[uintptr(unsafe.Pointer(t))][methodName] = method，其中t是reflect.TypeOf(&v).Elem() - 别缓存
reflect.Value或reflect.Value.Method(i).Call()的结果——它依赖具体实例，毫无复用价值 - 极端热路径可考虑
unsafe直接调用方法地址，但绕过类型系统校验，必须确保签名绝对匹配，否则 runtime crash
最容易被忽略的点是：即使你缓存了 reflect.Method，只要每次还走 reflect.Value.Call，就逃不开 receiver 校验和参数转换这两步开销。真正的取舍不在“要不要用反射”，而在于“能不能把反射动作移到构建期”。
