Go中无动态多态，反射调用reflect.Value.Call比直接调用慢50–100倍，因绕过编译期优化且需运行时查表、构造参数、接口转换；FieldByName是O(n)线性查找，非哈希索引，字段越多越慢。
Go 里没有“动态多态性”这个概念，所谓“反射实现的多态”本质是运行时类型分发，它不快、不安全、不可控——但某些场景下你确实绕不开。
reflect.Value.Call 比直接调用慢 50–100 倍，不是错觉
编译器对 add(1, 2) 能内联、去虚、做逃逸分析；而 v.Call(args) 必须在运行时查方法表、构造参数切片、检查可调用性、再跳转。整个过程绕过所有编译期优化。
更麻烦的是：v.Call() 返回的仍是 reflect.Value，若需取结果还得再 Interface() 一次，触发额外接口转换和堆分配。
- 一个空 struct 方法调用，直调耗时 ~2 ns，
reflect.Value.Call耗时 ~80–120 ns（Go 1.26 实测） - 高频路径（如 HTTP 中间件、gRPC 编解码）中反复调用，会显著抬高 P99 延迟
- Go 1.22+ 对部分反射路径做了微优化，但无法改变根本机制
FieldByName 是 O(n) 字符串查找，不是哈希索引
reflect.Value.FieldByName("ID") 内部线性遍历所有导出字段并做字符串比较，字段越多越慢，且无法被编译器优化。
立即学习“go语言免费学习笔记（深入）”；
实测一个 20 字段的 struct，FieldByName("ID") 比直接用 v.Field(0) 慢 5–8 倍；若字段带 json:"user_id" 这类 tag，解析也应在初始化阶段完成，不要每次反序列化都重解析。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 预扫描一次：
t := reflect.TypeOf(MyStruct{}); idx := -1; for i := 0; i ，后续直接 <code>v.Field(idx) - 字段名固定且已知时，硬编码索引（如
v.Field(1).SetString("x")），跳过名称查找 - 别缓存
reflect.Value实例——它绑定了具体值，不可复用，还可能阻止 GC
CanSet() == false？大概率你没传指针
想用反射改 struct 字段却 panic: reflect: cannot set，常见原因不是字段不可导出，而是你传进去的是值而非地址。
Go 反射要求“可设置”必须满足两个条件：值本身可寻址（addressable），且底层类型允许修改（比如非 const、非字面量）。
- 错误写法：
reflect.ValueOf(myStruct).FieldByName("Name").SetString("x") - 正确写法：
reflect.ValueOf(&myStruct).Elem().FieldByName("Name").SetString("x") - 注意：
reflect.ValueOf(&myStruct).Elem()才是那个可寻址的副本；如果原变量是函数返回的临时 struct，即使取地址也可能因逃逸不充分而不可寻址 - 字段名首字母小写（如
name string）无法通过反射修改，v.FieldByName("name").CanSet()永远返回false
缓存 Type 有用，缓存 Value 是陷阱
reflect.TypeOf(x) 缓存确实有效，因为它是只读元数据指针；但 reflect.ValueOf(x) 每次调用都会重新包装、检查、可能分配——它没法真正“复用”。
很多人以为“只调一次 reflect.TypeOf，后面复用”，就能解决性能问题。其实不然：Type 对象缓存确实有效，但 Value 是运行时快照，每次调用都开销不小。
- 别把
reflect.Value塞进map或全局变量里——它持有原始值引用，可能阻止 GC，且并发读写不安全 - 缓存 key 应该用
uintptr(unsafe.Pointer(reflect.TypeOf(x).UnsafePointer()))，而不是interface{}或Type.String() - 若真要提速，不如用代码生成专用 setter/getter，或预计算字段偏移数组，避免每次遍历
Type.NumField()
最易被忽略的一点：反射带来的不只是 CPU 开销，还有 GC 压力和逃逸分析失效。哪怕你只在启动时扫一遍结构体，只要用了 reflect.ValueOf 和 Interface()，就可能让本该栈分配的小对象跑到堆上——这点在内存敏感服务里会悄悄放大延迟毛刺。
