reflect.Value.Call 比直接调用慢10倍以上，因需动态解析签名、分配切片、类型检查、解包重包，且绕过编译期内联与寄存器优化；Go编译器几乎不对反射路径优化。
反射调用 reflect.Value.Call 为什么比直接调用慢 10 倍以上
因为每次 reflect.Value.Call 都要动态解析函数签名、分配临时参数切片、做类型检查、解包/重包值，还要绕过编译期的内联和寄存器优化。Go 编译器对反射路径几乎不做优化，所有操作都在运行时完成。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go test -bench=.对比obj.Method()和reflect.ValueOf(obj).MethodByName("Method").Call(nil)，典型差距在 8–15 倍 - 避免在 hot path（如 HTTP handler 内部、循环体）中使用
reflect.Call - 若必须动态调用，考虑提前用
reflect.Value缓存方法句柄（但注意：不能跨 goroutine 复用未导出字段的reflect.Value）
go:generate 生成的代码为何能接近原生性能
生成的代码是普通 Go 源文件，参与完整编译流程：类型检查、内联、逃逸分析、SSA 优化。没有运行时开销，也没有接口/反射间接层。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go:generate替代反射实现 JSON 序列化（如easyjson）、数据库扫描（如sqlc）、gRPC 客户端包装等场景 - 生成代码前务必加
//go:build ignore，防止被误编译进主包 - 生成逻辑里避免拼接复杂逻辑，优先用
text/template+ 结构化 AST（如go/ast）生成，而非字符串拼接
什么时候该忍着用反射，而不是硬上代码生成
反射不是敌人，而是权衡工具。当类型组合爆炸、变更频繁、或使用者无法控制生成时机时，代码生成反而增加维护成本。
典型适用反射的场景：
- 通用调试工具（如
pprof标签提取、gob编码器）—— 类型不可预知 - 测试辅助库（如
testify/assert的Equal）—— 要支持任意用户自定义类型 - 插件系统中加载未编译进主二进制的结构体（如 CLI 子命令注册）—— 无生成阶段
关键判断点：如果“类型集合”在编译期固定且稳定，优先生成；如果它由外部输入（配置、网络、用户代码）决定，反射更现实。
混合方案：用生成代码兜底，反射 fallback
比如 ORM 库可先尝试从 gen/ 目录加载已生成的 ScanXXX 函数，失败则退回到 reflect.StructField 解析。既保住了热路径性能，又不牺牲灵活性。
实操要点：
- 生成代码导出明确的接口（如
type Scanner interface { ScanRow(*sql.Rows) error }），运行时用interface{}断言判断是否可用 - fallback 路径需加日志告警（如
log.Warn("using reflect fallback for type %s", typ.Name())），便于发现未覆盖类型 - 禁止在生成代码中写
panic或阻塞 IO，否则 fallback 机制失效
func NewScanner(typ reflect.Type) Scanner {
if genScanner, ok := genScanners[typ]; ok {
return genScanner
}
return &reflectScanner{typ: typ} // fallback
}
反射和生成不是非此即彼的选择，真正难的是界定「哪些类型值得生成」「哪些调用频次值得优化」「哪些错误该在构建期暴露」——这些边界往往藏在监控数据和 profile 结果里，而不是设计文档中。 
