reflect.TypeOf() 非零成本，热点路径中比类型断言慢10–50倍，应缓存结果、避免循环调用、用(*T)(nil).Elem()获取类型，优先用Kind()而非Name()判断类型类别。
reflect.TypeOf() 调用本身就有开销
每次调用 reflect.TypeOf() 都会触发一次接口值拆包、类型元数据查找和反射对象构造，这不是零成本操作。实测在热点路径中反复调用，比直接用已知类型做判断慢 10–50 倍（取决于类型复杂度）。它还会阻止编译器内联和部分逃逸分析优化。
常见错误现象：在循环里对每个元素都调用 reflect.TypeOf(item) 判断类型；或在 HTTP handler 中对每个请求参数都重新获取 reflect.Type。
- 如果目标类型固定且已知，优先用类型断言（
v, ok := item.(MyStruct)）或类型 switch - 若必须用反射，把
reflect.TypeOf()结果缓存为包级或结构体字段变量，比如var userType = reflect.TypeOf((*User)(nil)).Elem() - 避免对
nil interface{}调用 —— 会 panic，需提前判空
不用实例也能拿到 reflect.Type：(*T)(nil).Elem()
很多场景下你只需要类型信息，但又不想构造一个真实对象（比如结构体带不可导出字段、初始化开销大，或根本没定义变量）。这时不能写 reflect.TypeOf(User{})，因为那会触发实例化和内存分配。
正确做法是用空指针取类型：reflect.TypeOf((*User)(nil)).Elem()。原理是：(*User)(nil) 是合法的类型字面量表达式，不分配内存，只携带类型信息；reflect.TypeOf 拿到的是 *User 的 reflect.Type，再调 .Elem() 就得到 User 本体。
立即学习“go语言免费学习笔记（深入）”；
- 这个技巧适用于所有命名类型（struct、interface、custom int 等），但对未命名类型（如
[]int）只能用reflect.TypeOf([]int(nil)) - 注意不要漏掉
.Elem()，否则你会拿到指针类型，Kind()返回Ptr而非Struct - 缓存这种结果非常安全，
reflect.Type是只读、可并发读、无状态的
Kind() 和 Name() 的行为差异容易混淆
Kind() 返回底层基础分类（reflect.Struct、reflect.Slice 等），而 Name() 只对命名类型返回非空字符串。比如 type MyInt int 的 Name() 是 "MyInt"，但 type int 的别名（如 type ID int）的 Name() 才有值；而 []string 或 map[int]string 的 Name() 永远为空，Kind() 才是 reflect.Slice 或 reflect.Map。
- 做类型路由时，优先用
Kind()判断大类，再用Implements()或AssignableTo()做精确匹配 - 依赖
Name()做配置映射？要先确认该类型是否被显式命名，否则逻辑会静默失效 -
PkgPath()在跨包类型比较时有用，但同名不同包的类型Name()相同，PkgPath()不同
reflect.Type 本身不是“昂贵”的资源，但误用会让它变重
reflect.Type 接口值本身很小（几个指针大小），复用它几乎没成本。真正拖慢性能的是反复调用 reflect.TypeOf()、频繁调 FieldByName()（线性搜索）、或在循环里对每个字段调 Field(i) 却没缓存字段索引。
容易被忽略的一点：结构体字段遍历时，NumField() 是 O(1)，但 FieldByName("xxx") 是 O(N) —— 如果你在解析 JSON tag 时对每个字段都查一遍名字，不如提前建个 map[string]int 缓存字段位置。
- 字段多的结构体（>20 字段），务必预构建字段名 → 索引映射表
- 方法调用前，用
MethodByName()获取reflect.Value后可缓存，避免重复查找 - 不要在 defer 或 recover 里用反射做类型检查 —— panic 恢复路径本就慢，加反射雪上加霜
