反射调用在高并发场景下性能极差，reflect.Value.Call() 耗时达78.4 ns/op，是直调的65倍；encoding/json 等标准库大量隐式使用反射，需通过预生成序列化函数、延迟解析、初始化阶段缓存类型信息等方式优化。
反射调用在高并发场景下会显著拖慢性能，不是“能用就行”的问题，而是“一用就卡顿”的实际瓶颈。
reflect.Value.Call() 的开销远超直调
Go 反射调用函数或方法时，reflect.Value.Call() 会触发完整的类型检查、参数转换、栈帧构造和运行时调度。实测数据显示：direct call 平均耗时约 1.2 ns/op，而 reflect.Value.Call() 高达 78.4 ns/op —— 差距超 65 倍。在每秒处理数万请求的 API 服务中，哪怕只对 1% 的请求路径走反射，延迟毛刺也会明显可感。
- 每次
Call()都要重新解析参数类型，无法复用；而普通函数调用在编译期就完成绑定 - 反射调用无法内联，编译器完全放弃优化机会
- 如果传入参数是接口类型（如
interface{}），还会额外触发接口 pair 拆包，进一步放大开销
JSON 序列化里偷偷用的 reflect 是性能重灾区
标准库 encoding/json 在 Marshal/Unmarshal 时大量依赖反射解析结构体字段和标签。它不是“只用一次”，而是在每个请求中反复执行：读取字段名、检查 json: 标签、判断是否导出、转换类型……这些操作在高并发下迅速累积成可观延迟。
- 避免在热路径上对未知结构体做
json.Marshal(v)；若类型固定，优先用预生成的序列化函数（如通过easyjson或ffjson生成） -
json.Unmarshal对大 payload 尤其敏感，反射需遍历全部字段；可考虑先用json.RawMessage延迟解析，仅按需解特定子字段 - 别在
http.HandlerFunc内直接对请求体做多次json.Unmarshal—— 一次解析、多次复用值，而不是反复反射
想绕过反射？得提前“固化”类型信息
真正可行的优化不是“少用反射”，而是“让反射只发生一次”。核心思路是把运行时的动态行为，提前到初始化阶段完成类型探测和函数绑定。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Once+ 全局变量缓存reflect.ValueOf(fn).Call所需的reflect.Value参数模板，避免每次请求都调用reflect.ValueOf - 对常用结构体，手写或代码生成专用的
FromMap/ToJson方法，彻底跳过encoding/json - Web 框架路由绑定时，不要在 handler 里用反射调用用户函数；改用接口抽象（如
type Handler interface { ServeHTTP(...) }），靠编译期多态替代运行时反射
高并发系统里，反射不是“不能用”，而是它的代价必须被看见、被隔离、被缓存。最危险的不是写了一次 reflect.Value.Call()，而是没意识到它会在每毫秒被调用数百次。
