reflect.ValueOf 和 reflect.TypeOf 的基础开销极小，通常在纳秒级；前者获取值信息并封装为 reflect.Value，后者仅提取动态类型元数据（如 rtype），不涉及值拷贝或运行时查找，性能高效。
reflect.ValueOf 和 reflect.TypeOf 的基础开销有多大
直接调用 reflect.ValueOf 或 reflect.TypeOf 本身开销极小，通常在纳秒级（Value 的操作。
比如 v := reflect.ValueOf(x); v.Interface() 这一来回，在小结构体上可能增加 50–100ns；若 x 是大 slice 或嵌套 map，v.Interface() 会触发深拷贝，开销直接跳到微秒甚至毫秒级。
- 避免在 hot path 中反复调用
reflect.ValueOf：缓存reflect.Type和reflect.Value（如果值不变） -
reflect.ValueOf(&x).Elem()比reflect.ValueOf(x)多一次指针解引用，但避免了值拷贝——适合只读或需地址操作的场景 - 注意
reflect.Value的CanInterface()返回 false 时调用Interface()会 panic，常见于 unexported 字段或非 addressable 值
struct 字段遍历 + set/get 的典型瓶颈在哪
用 reflect.Value.NumField() 遍历字段、再用 v.Field(i).Set() 或 v.Field(i).Interface() 是最常被误用的重灾区。每次 Field(i) 都生成新 reflect.Value，且 Set() 要校验可寻址性、类型一致性，开销远超原生字段访问。
实测一个 10 字段的 struct，原生赋值耗时 ~2ns/字段；用 reflect 逐个 Set() 平均 80–120ns/字段，相差 40 倍以上。更糟的是，如果字段含 interface{} 或 map，反射 set 还可能触发额外分配。
- 字段名查找（
v.FieldByName("Foo")）比索引访问（v.Field(0)）慢 2–3 倍，因要哈希查表 -
v.SetMapIndex()或v.SetLen()等方法内部有较多边界检查，比原生操作多 10–20 次函数调用 - 如果只是做一次性的结构转换（如 JSON 解析后映射），开销可接受；但若在每请求循环中执行，就是性能热点
和 unsafe.Pointer / code generation 对比的实际差距
用 unsafe.Pointer 手动偏移取字段，或用 go:generate + github.com/tinylib/msgp 类工具生成专用 marshaler，性能可逼近原生代码。实测相同 struct 的序列化：纯反射实现约 1.2μs，生成代码约 0.08μs，差 15 倍；内存分配上，反射版平均多出 3–5 次堆分配。
这不是理论差距——Go 标准库里 encoding/json 在 Go 1.19+ 已对常见类型（int, string, struct）启用“fast-path”，绕过反射；只有 fallback 路径才进 reflect.Value。你可以用 go tool compile -gcflags="-m" your_file.go 看是否逃逸到反射路径。
- 不要假设 “用了 reflect 就一定慢”：简单
reflect.TypeOf(x).Name()对性能无感 - 但凡涉及循环、高频调用、或大数据量操作，优先考虑
unsafe（需确保内存布局稳定）或生成代码 -
reflect.StructTag解析（如json:"name,omitempty"）本身很快，但反复调用v.Type().Field(i).Tag.Get("json")会重复解析 tag 字符串——建议启动时预解析并缓存为 map
哪些场景下 reflect 开销其实可以忽略
命令行参数绑定、配置文件加载、单元测试断言、HTTP handler 初始化阶段的结构注册——这些都是一次性或低频行为。哪怕单次耗时 100μs，在整个程序生命周期里占比几乎为零。
关键看调用频次与数据规模：如果你的 RPC 服务每秒处理 10k 请求，每个请求反射解析 1 个 struct，那这部分就贡献了 ~1ms 的 P99 延迟；但如果只是 CLI 工具启动时读一个 YAML 配置，那怎么写都行。
- 用
benchstat对比真实 workload：别只 bench 单个reflect.Value.Field(0)，要包一层业务逻辑 - pprof 的
cpu profile里搜reflect.Value相关符号，看是否出现在 top 函数中——没出现就不用优化 - Go 1.21 引入的
reflect.Value.UnsafeAddr()仍受限于类型安全检查，不能完全替代unsafe.Offsetof，别指望它“免费”
反射不是银弹，也不是洪水猛兽。它真正的代价不在第一行 reflect.ValueOf，而在你不知不觉把它塞进了 for 循环、defer 链、或者每毫秒都调用的回调里。
