学完这篇，你能搞清楚 Go 反射慢在哪里、什么时候该用、怎么把它的开销压到可以接受的程度。
第一步：先把 Type、Value、Kind 分清
反射的入口只有两个函数：
t := reflect.TypeOf(x) // 类型信息，只读、可缓存
v := reflect.ValueOf(x) // 值信息，可读、可改（有条件）
新手最容易混的是 Type 和 Kind。Kind 是底层表示（Struct、Ptr、Slice…），Type 是具体类型（User、*User）。写通用逻辑时判断 Kind，写特定逻辑时判断 Type。
var u User
t := reflect.TypeOf(u)
fmt.Println(t.Name()) // User
fmt.Println(t.Kind()) // struct
fmt.Println(t.NumField(), t.Field(0).Name, t.Field(0).Type)
Type 是接口，背后是运行时的 *rtype，同一种类型全局只有一份，所以它是天然可缓存的。Value 则携带具体数据，不能跨值复用。
第二步：记住三条定律，能少踩一半坑
- 接口值 → 反射对象：
reflect.ValueOf(x)，这一步会把 x 装箱成 interface{}。
- 反射对象 → 接口值：
v.Interface()，这一步又会装箱一次。
- 想修改值，必须是可设置的（settable）：传指针再
Elem()。
x := 0
v := reflect.ValueOf(x)
// v.SetInt(1) // panic: reflect: reflect.Value.SetInt using unaddressable value
v = reflect.ValueOf(&x).Elem()
v.SetInt(1) // ok
注意：v.CanSet() 返回 false 时不要去试 Set，直接 panic。判断前先看 v.IsValid()，reflect.ValueOf(nil) 拿到的是零值 Value，对它做任何操作都会 panic。
第三步：性能到底损失在哪几处
实测经验值（不同机器有差异，但量级稳定）：
| 操作 | 直接写 | 反射 |
|---|
| 结构体字段赋值 | ~1 ns | ~100–200 ns |
| 方法调用 | ~2 ns | ~200–400 ns |
DeepEqual 比较小结构 | ~5 ns | ~500 ns+ |
慢的原因具体是四条：
- 装箱与逃逸：
ValueOf 把值塞进 interface{}，编译器常常被迫在堆上分配。
- 运行时查找：
Field(i)、MethodByName("X") 每次都要做边界检查和字符串比较。
- 无法内联：反射路径全部是函数调用，编译器的内联和常量传播全部失效。
- 边界与类型检查：每次
Set/Get 都有 flag 校验。
注意：reflect.DeepEqual 是热路径杀手，它有大量递归和接口比较，能用 ==、手写 Equal 或生成的比较函数替代就别用它。
第四步：四条优化路径，按性价比排序
1）先走类型断言快路径，失败再反射
func toString(v any) string {
if s, ok := v.(string); ok { // 99% 的调用走这里
return s
}
return fmt.Sprint(v) // 冷路径
}
2）缓存 Type 和字段索引
type fieldMeta struct {
index int
name string
}
var fieldCache sync.Map // reflect.Type -> []fieldMeta
func fieldsOf(t reflect.Type) []fieldMeta {
if v, ok := fieldCache.Load(t); ok {
return v.([]fieldMeta)
}
n := t.NumField()
fs := make([]fieldMeta, 0, n)
for i := 0; i < n; i++ {
f := t.Field(i)
if f.PkgPath != "" { // 跳过未导出字段
continue
}
fs = append(fs, fieldMeta{index: i, name: f.Name})
}
fieldCache.Store(t, fs)
return fs
}
缓存后，字符串比较和边界检查只做一次，热点循环里只剩 Field(i) 的取值本身。
3）能生成代码就别反射
序列化、枚举字符串、ORM 映射这类结构固定的场景，用 easyjson、stringer、sqlc 之类工具生成代码，性能直接回到“手写”水平。反射适合结构在运行时才知道的场景，比如通用配置解析、插件参数绑定。
4）确实要极限性能，再考虑 unsafe 算字段偏移
off := t.Field(i).Offset
p := unsafe.Pointer(&s)
fieldPtr := (*int)(unsafe.Pointer(uintptr(p) + off))
这样可以把每次访问压到几纳秒，但代价是彻底放弃类型安全和 GC 逃逸保护。
注意：不要用 unsafe 去读写未导出字段。这既违反语言规范，也会在开启 -gcflags=-d=checkptr 或未来版本里直接崩掉，且 go vet 会报警。真正需要时，把逻辑收进一个包内、加清楚注释、写死测试。
第五步：一个实用判断标准
在写反射代码前问自己一句：这段代码每次请求都会跑，还是启动时跑一次？
- 启动/初始化阶段（解析 tag、注册路由、绑定配置）——放心用反射，怎么方便怎么来。
- 每请求、每元素的热循环——必须缓存元信息 + 快路径断言，否则老老实实生成代码。
还要记得给反射入口做入参校验：Kind 不匹配直接返回错误，别让 panic 冒到业务层。生产代码里，反射部分的 panic 最好用 recover 兜一层，转成 error 返回。
小结
TypeOf 拿类型（可缓存、全局唯一），ValueOf 拿值（带数据、不可复用）。- 判断用
Kind，匹配用 Type；改值必须先取地址再 Elem()，并检查 CanSet。
- 反射慢在装箱逃逸、运行时字符串查找、无法内联三件事上，量级是 50–200 倍。
- 优化顺序：类型断言快路径 → 缓存
Type/字段索引 → 代码生成 → unsafe（最后手段）。
DeepEqual 不进热路径；未导出字段不用 unsafe 硬碰。- 初始化阶段用反射、热路径用生成代码，这条线划清楚，性能问题基本不会出现。
星耀SVIP
见习用户
正式会员
认证极客
钻石卡会员
