reflect.typeof和reflect.valueof不可在循环中反复调用，因每次均触发堆分配（单次约48字节）和运行时类型查找，实测空结构体下调用耗时12–18 ns；fieldbyname是o(n)线性搜索，20字段结构体耗时约80 ns，而field(i)仅需不到2 ns；call的瓶颈主要在receiver校验与参数匹配，非调用本身。
直接测 reflect.TypeOf、reflect.ValueOf、FieldByName 和 Call 这四个函数的开销，比泛泛谈“反射慢”有用得多——它们各自瓶颈不同，优化策略也完全不同。
为什么 reflect.TypeOf 和 reflect.ValueOf 不能在循环里反复调用
这两个函数每次调用都触发堆分配和运行时类型查找，不是轻量操作。实测在空结构体上，单次 reflect.ValueOf 平均分配 48 字节、耗时 12–18 ns；若在每秒 10 万次的循环中重复调用，GC 压力会明显上升，B/op 从 0 涨到 4.8M/op。
- 必须提前缓存
reflect.Type和reflect.Value：比如把reflect.TypeOf(&MyStruct{}).Elem()存为全局变量 - 别用
interface{}当 map key 缓存类型信息——不同变量即使类型相同，map[interface{}]T也无法命中；应改用uintptr(unsafe.Pointer(t)) -
reflect.ValueOf(x)传值 vs 传指针影响很大：对结构体传值会复制整个 struct，传指针则只复制地址，且后续CanSet()才可能为 true
FieldByName 在字段多时为何突然变慢
FieldByName 是线性搜索，不建索引。20 字段结构体平均耗时约 80 ns；字段数翻倍，耗时几乎翻倍。而用预存的字段索引 Field(i) 只需不到 2 ns。
- 字段名拼写错误或大小写不符时，返回零值
reflect.Value，IsValid()为 false —— 不检查就调SetString()会 panic - 未导出字段（小写首字母）无法被
FieldByName访问，强行访问不会报错但结果不可用 - 高频路径上应预计算字段偏移：用
t.FieldByName("Name").Index获取索引后，后续直接v.Field(i)，避免重复字符串匹配
reflect.Value.Call 的 panic 大部分源于 receiver 不合法
Call 本身不是最重的环节，真正卡在调用前的校验：receiver 是否可寻址、参数类型是否严格匹配、方法是否存在。一次失败的 Call 可能只花 50 ns，但 panic 后恢复成本远高于此。
- 值接收器方法可用
reflect.ValueOf(t)或reflect.ValueOf(&t).Elem()；指针接收器方法必须用reflect.ValueOf(&t)，且t不能是 nil -
method := v.MethodByName("Foo")后务必先判断method.IsValid() && method.CanCall()，否则 panic 信息极简陋（如 “call of reflect.Value.Call on zero Value”） - 参数必须是
[]reflect.Value，每个元素类型要和签名完全一致：int 和 int64 视为不同，不调.Convert()就 panic - 缓存
reflect.Method有效，缓存reflect.Value几乎无用——前者是只读全局单例，后者每次新建
基准测试怎么写才反映真实开销
用 go test -bench=. 测反射，最容易误判的是没隔离干扰项。比如忘了 b.ResetTimer()，或把初始化逻辑塞进循环里，测出来的就不是函数本身开销。
- 必须调
b.ReportAllocs()：反射的性能瓶颈常在内存分配，而非 CPU 时间 - 结构体要带真实字段（如含
[]string或嵌套 struct），否则测不出嵌套导致的指数级衰减 - 禁用内联（
-gcflags="-l"）能让结果更贴近生产环境，但注意：它会让反射更差，不是 bug，是去掉了编译器的“作弊” - 对比组一定要有：比如同一结构体的手写赋值函数，才能看出反射慢多少倍（通常 8–12 倍起）
真正卡住性能的，往往不是某一行反射调用，而是没意识到 FieldByName 是 O(n)、ValueOf 会逃逸、Call 前的校验无法跳过——这些细节不抠清楚，光靠“少用反射”这种建议解决不了问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
