reflect.typeof 和 reflect.valueof 开销大，因需接口装箱和运行时查表；kind() 本身廉价但依赖已构造的 type/value；高频路径应缓存类型或改用泛型，避免循环内重复调用。
reflect.TypeOf 和 reflect.ValueOf 本身就有开销
这两个函数看似只是“读取”类型信息，但每次调用都会触发接口装箱（interface{} 包装）和运行时类型元数据查找。哪怕你只做 reflect.TypeOf(x).Kind()，也必须先构造一个 eface，再从其中提取 _type 指针——这不是纯内存读取，而是带安全检查的查表操作。
实测在热点循环中调用 reflect.TypeOf(x)，比直接用类型开关或类型断言慢 15–30 倍；如果后续还调用 .Name() 或 .Field(0)，开销会指数级上升。
- 传入非导出字段或 nil 接口时，
reflect.ValueOf不 panic，但后续调用.Kind()或.Type()会 panic —— 必须先v.IsValid() -
reflect.TypeOf对interface{}返回的是底层实际类型（如*MyStruct），不是interface{}本身，这点常被误认为“类型丢失” - 避免在 for 循环内反复调用它们；高频路径应提前缓存
reflect.Type或改用泛型
Kind() 是 cheap，但前提是 Type/Value 已存在
Kind() 本身只是读取 _type.kind 字段，属于 O(1) 内存访问，确实便宜。但它的前提是你已经有合法的 reflect.Type 或 reflect.Value —— 而获得它们的过程才是瓶颈。
比如下面这段代码看着轻量，其实不高效：
func isInt(v interface{}) bool {
return reflect.TypeOf(v).Kind() == reflect.Int // ❌ 每次都装箱+查表
}
更合理的写法是把类型判断移到编译期，或至少缓存 reflect.Type：
var intType = reflect.TypeOf(int(0)) // ✅ 静态初始化一次
func isInt(v interface{}) bool {
return reflect.TypeOf(v).Kind() == intType.Kind()
}
-
Kind()安全的前提是：对象已通过reflect.TypeOf或reflect.ValueOf正确获取，且未被nil或非法指针污染 -
reflect.Struct、reflect.Slice等常量是编译期确定的整数，比较无开销；但它们的来源（即.Kind()调用）不是免费的 - 不要为了省一行代码，在 hot path 上重复构造
reflect.Type
结构体字段遍历的开销远超 Kind 判断
真正拖慢反射性能的，往往不是 Kind()，而是对结构体字段的深度访问：比如 t.Field(i)、v.Field(i).Interface()、v.Field(i).SetXXX()。这些操作涉及字段偏移计算、标签解析、可设置性检查、堆分配（.Interface() 会逃逸）等。
例如这个常见误用：
for i := 0; i
-
v.Field(i).Interface()是最重的操作之一，比直接取值慢 20–50 倍；能用.Int()/.String()就别用.Interface() - 遍历字段前，先确认
v.Kind() == reflect.Struct且v.CanAddr()（否则无法修改） - 非必要不调用
.Tag.Get("xxx")—— 标签解析是字符串查找，比字段访问还慢一点
为什么缓存 Type/Value 能显著提速
Go 的类型元数据在二进制里是只读常量，reflect.Type 和 reflect.Value 的构造成本主要花在“定位”和“包装”上，而不是“读取”。一旦你拿到一个 reflect.Type，后续所有 .Kind()、.Name()、.Field() 都是零分配、无查表的内存访问。
典型优化模式：
var userStructType = reflect.TypeOf(User{}).Elem() // 缓存 *User 的 struct Type
func fillUser(v interface{}) {
rv := reflect.ValueOf(v)
if rv.Type() != userStructType { // 直接指针比较，O(1)
panic("wrong type")
}
// 后续字段操作都基于已知 Type，跳过动态查找
}
- 缓存
reflect.Type适用于类型固定的场景（如 ORM 映射固定 struct） - 缓存
reflect.Value更少见，因为 Value 包含具体值状态；但reflect.ValueOf(&x).Elem()可缓存用于反复 set - 注意：缓存的是
reflect.Type，不是reflect.TypeOf(x)的结果表达式 —— 后者每次执行仍会触发装箱
真正影响性能的从来不是 Kind() 这个调用，而是你为了拿到能调用 Kind() 的那个 reflect.Type 所做的全部动作。越早把反射“固化”到初始化阶段，运行时就越轻量；越晚、越频繁地在业务逻辑里现场生成，就越容易踩坑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
