反射在go中可用于序列化器、orm映射等，但reflect.value.call比直接调用慢数十倍，因绕过编译期优化且触发额外分配；高频路径应避免反射，优先用代码生成或unsafe优化。
Go 框架里用反射，不是“能不能用”，而是“在哪用、怎么控、值不值得换”。它确实能帮你写出通用序列化器、ORM 字段映射、依赖注入容器，但每调一次 reflect.ValueOf、reflect.Value.Call 或遍历结构体字段，都在悄悄吃掉 CPU 和 GC 压力。
为什么 reflect.Value.Call 比直接调用慢几十倍
编译器对普通函数调用能内联、去虚、做逃逸分析；而 reflect.Value.Call 必须在运行时查方法表、构造参数切片、检查可调用性、再跳转——整个过程绕过所有编译期优化。更麻烦的是，它返回的仍是 reflect.Value，若需取结果还得再 Interface() 一次，触发额外接口转换和堆分配。
- 实测：一个空 struct 方法调用，直调耗时 ~2 ns，
reflect.Value.Call耗时 ~80–120 ns（取决于 Go 版本和 CPU） - 高频路径（如 HTTP 中间件、gRPC 编解码）中反复反射调用，会显著抬高 P99 延迟
- Go 1.22+ 对部分反射路径做了微优化，但无法改变根本机制
CanSet() 失败却没报错？先看是否传了指针
想用反射改 struct 字段，却遇到 v.CanSet() == false，常见原因不是字段不可导出，而是你传进去的是值而非地址。Go 反射要求“可设置”必须满足两个条件：值本身可寻址（addressable），且底层类型允许修改（比如非 const、非字面量）。
- 错误写法：
reflect.ValueOf(myStruct).FieldByName("Name").SetString("x")→ panic: reflect: cannot set - 正确写法：
reflect.ValueOf(&myStruct).Elem().FieldByName("Name").SetString("x") - 注意：
reflect.ValueOf(&myStruct).Elem()才是那个可寻址的副本；如果原变量本身是栈上临时值（如函数返回的 struct），即使取地址也可能因逃逸不充分而不可寻址
缓存 reflect.Type 和 reflect.Value 能缓解但不能根治性能问题
很多人以为“只调一次 reflect.TypeOf，后面复用”，就能解决性能问题。其实不然：类型对象（reflect.Type）缓存确实有效，因为它只是元数据指针；但 reflect.Value 是运行时快照，每次调用 reflect.ValueOf(x) 都会重新包装、检查、可能分配 —— 它没法真正“复用”。
- 推荐做法：对固定类型（如已知的 config struct）提前缓存
reflect.Type和字段偏移数组，避免每次遍历Type.NumField() - 避免缓存
reflect.Value实例，尤其别把它塞进 map 或全局变量里 —— 它持有原始值引用，可能阻止 GC，且并发读写不安全 - 若真要提速，不如用
unsafe.Offsetof+ 类型断言生成静态访问器，或直接上go:generate生成专用 setter/getter
真正难处理的，从来不是“怎么用反射”，而是“哪条路径必须用、哪条其实可以不用”。比如 JSON 解析器里字段映射用反射很自然，但如果你正在写一个高性能 metrics collector，连每个采样点都要走一遍 Value.FieldByName，那不如花半天时间生成 type-specific marshaler —— 后者零分配、无反射开销、P99 延迟降得下来，维护成本也并不更高。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
