不适合在高并发路径中使用反射，因其类型遍历、字段查找、调用栈重建等开销巨大，吞吐量仅为代码生成版的1/32且延迟抖动剧烈；仅适合配置加载、ORM初始化等低频可缓存场景。
不适合，除非做了严格缓存或仅用于初始化阶段。
Go 反射在高并发路径中会成为显著瓶颈——它不是“慢一点”，而是慢几十倍且不可预测。你不能靠加机器或调 GOMAXPROCS 来掩盖这个问题。
为什么反射在高并发下特别伤性能
反射的开销不是线性的，而是集中在几个关键环节：
-
reflect.TypeOf和reflect.ValueOf每次调用都要做类型系统遍历，无法被编译器内联 - 字段/方法查找（如
t.FieldByName）需哈希扫描，无缓存时是 O(n)；而结构体字段越多，越拖慢 - 每次
reflect.Value.Call都触发完整调用栈重建 + 参数复制，比直接函数调用多 20~50 倍 CPU 指令 - 频繁反射会导致变量逃逸到堆，加剧 GC 压力——你在压测时看到的
GC Pause 2–3s，往往就来自没控制住的反射分配
实测数据（Go 1.21）：对同一结构体反复序列化，纯反射版本吞吐量只有代码生成版的 1/32，且 P99 延迟抖动剧烈。
立即学习“go语言免费学习笔记（深入）”；
哪些场景能“安全”用反射
反射不是不能用，而是必须隔离在「低频、确定、可缓存」的边界内：
-
配置加载期：服务启动时解析 YAML/JSON 标签，缓存
reflect.Type和字段偏移，后续请求走预计算路径 -
ORM 映射初始化：第一次访问某 model 时构建
fieldCache sync.Map，之后所有 CRUD 都绕过反射 -
RPC 接口注册：在
init()或main()中完成方法发现，运行时只查表 dispatch
反例：在 HTTP handler 里对每个请求都 json.Unmarshal + reflect.Value.SetMapIndex —— 这等于给每秒万级请求配了个解释器。
替代方案：生成代码比优化反射更有效
Go 生态已成熟支持编译期生成，把反射成本前置到构建阶段：
- 用
go:generate+stringer/mockgen生成类型专用序列化函数 - 基于
ent或sqlc的 ORM 工具，直接产出无反射的 CRUD 方法 - 自定义
gengo插件，将 struct tag 转为静态字段数组，运行时只做数组索引
type User struct {
ID int64 `json:"id" db:"id"`
Name string `json:"name" db:"name"`
}
// 生成的代码类似：
func (u *User) MarshalJSON() ([]byte, error) {
return []byte(`{"id":`+strconv.AppendInt(nil, u.ID, 10)+`,"name":`+strconv.Quote(u.Name)+`}`), nil
}
这种方案没有 runtime 反射，零 GC 分配，性能逼近手写，且 IDE 可跳转、可调试。
真正难的不是“会不会用反射”，而是判断哪条调用路径必须动态、哪条其实只是懒得多写几行生成逻辑。高并发系统里，宁可多花 2 小时写个 generator，也不要让一个 reflect.Value.Interface() 在 hot path 上跑满一整天。
