Go项目中反射在高频路径中禁用，因reflect.ValueOf/TypeOf和FieldByName会引发堆分配、类型查找及线性搜索等硬开销；应预缓存类型信息、用FieldByIndex替代FieldByName、规避reflect.Value.Call，并优先采用代码生成或接口抽象。
Go 项目里反射不是不能用，而是高频路径中反复调用 reflect.ValueOf、reflect.TypeOf 或 FieldByName 会直接拖垮吞吐——这不是“写法问题”，是运行时查表、堆分配、逃逸分析失效叠加导致的硬性开销。
热路径中禁止重复调用 reflect.ValueOf 和 reflect.TypeOf
HTTP handler、gRPC 方法入口、消息循环体这些每秒执行成千上万次的地方，绝不能出现 reflect.ValueOf(req) 这类调用。每次调用都触发类型元数据查找 + 新建 reflect.Value 实例（约 96 字节堆分配），GC 压力和 CPU 时间都会指数级上升。
- 正确做法：把类型信息提取逻辑移到
init()或首次访问时，用sync.Once初始化全局缓存，key 是reflect.Type指针（它本身是并发安全且地址唯一） - 错误示范：
for _, item := range items { v := reflect.ValueOf(item); ... }—— 即使 item 类型相同，也每次新建Value - 注意：别用
map[interface{}]T缓存，interface{}作 key 无法命中；更别用Type.String()转字符串当 key，额外分配 + 哈希开销
FieldByName 必须替换为 FieldByIndex 或预计算索引映射
FieldByName 是线性搜索，字段越多越慢，100 字段结构体平均要比对 50 次字符串。它还无法内联、不参与编译期优化，纯 runtime 开销黑洞。
- 优先方案：启动时用
t.FieldByName("ID")查一次，记下索引（比如 0），后续一律用v.Field(0).Int()—— 基准测试显示快 3–5 倍，零分配 - 通用方案：用
sync.Map缓存reflect.Type → map[string]int，key 是字段名，value 是FieldByIndex所需的[]int（例如[]int{0}或[]int{1, 2}表示嵌套字段） - 坑点：缓存未处理指针解引用（
v.Elem().FieldByName）或匿名字段，运行时查不到字段却返回零值，静默失败
动态方法调用必须规避 reflect.Value.Call
reflect.Value.Call 是 Go 反射里最重的操作之一，每次都要校验参数类型、打包 reflect.Value 切片、拆包、跳转、再打包返回值。空函数直调约 2 ns，Call 常达 20–200 ns，慢 10–100 倍。
- 硬性要求：绝不允许在热路径中出现
v.MethodByName("Handle").Call(args) - 可行替代：
fn := v.Method(0).Func提前拿到函数指针，后续直接fn.Call(args)；但注意Method(i)依赖方法定义顺序，不如MethodByName稳定，需文档注明 - 更优解：用泛型封装分发逻辑，或定义接口（如
Processor），让具体类型自行实现，彻底绕过反射
能用代码生成就别碰运行时反射
90% 的 ORM 映射、JSON 序列化、配置绑定场景，类型集合其实是静态可枚举的。把反射逻辑搬到构建期，性能提升是数量级的——不是“优化”，是消除。
- 立即可用方案：用
sqlc替代database/sql+ struct 反射扫描；用msgp替代encoding/json；用ent替代手写 GORM 风格映射 - 自研生成：用
go:generate扫描 struct tag，为每个目标类型生成专用的Scan()、UnmarshalJSON()函数，签名与标准库一致，便于灰度替换 - 关键约束：CI 中必须校验
go generate后无 diff，否则类型变更后生成代码滞后，panic 在运行时才暴露
真正难的不是写出能跑的反射代码，而是判断某处逻辑是否真的需要反射——比如日志字段提取只涉及 3 种结构体，却写了通用 interface{} + FieldByName，这种“灵活性”只会掩盖设计缺陷。反射该用在框架底层，而不是业务主干。
