直接用 reflect.kind 比较更快，因其是整数比较；而 reflect.typeof 需查表、分配内存、接口转换，开销高一个数量级，且 reflect.typeof(v) == reflect.typeof("") 永远为 false。
直接用 reflect.Kind 比较，别调 reflect.TypeOf 或 reflect.ValueOf 做类型对象比对——前者是整数比较，后者要查表、分配、接口转换，开销高一个数量级。
为什么 Kind() 比 TypeOf() 快得多
因为 reflect.Kind 是个 int 常量（比如 reflect.String == 2），v.Kind() == reflect.String 就是一次整数比较；而 reflect.TypeOf(x) 要走类型系统查找、构造 reflect.Type 接口对象、触发接口转换，还会分配内存。
常见错误写法：reflect.TypeOf(v) == reflect.TypeOf("")，这永远为 false（两个不同地址的接口值），且每次调用都新建对象。
- 所有泛型还没覆盖的动态分支场景（如通用日志字段提取、配置解析），优先用
switch v.Kind() - 若需进一步区分自定义类型名（如
type MyInt int），再补一层v.Type().Name()，但不要在热路径里反复调 -
reflect.Kind的整数值是文档保证稳定的（Int = 2），比字符串拼接或包路径拼 key 更可靠
判断前必须检查 IsValid() 和 CanInterface()
未初始化的接口变量（var v interface{}）、nil 指针解引用后、未导出字段的 Value，都可能导致 Kind() 返回 Invalid 或后续操作 panic。
- 先
if !v.IsValid() { return }，再取v.Kind() - 想调
v.Interface()得加v.CanInterface()，否则对不可导出字段或未寻址值会 panic - 指针类型要两步：先
v.Kind() == reflect.Ptr，再!v.IsNil()，才能安全v.Elem()
避免在循环里重复调 Kind()
虽然 Kind() 本身极快，但在高频结构体遍历、JSON 解码内层循环中，反复调用仍会累积可观开销——尤其是当编译器无法内联时。
- 把
v.Kind()结果存到局部变量，比如kind := v.Kind()，后续分支全用它 - 对已知结构体字段，直接用类型断言（
if u, ok := data.(User)）替代反射分支，快一个数量级且不逃逸 - 若必须反射，把
Kind()分支和字段访问逻辑一起缓存（比如预计算fieldInfo结构体），而不是只缓存类型
真正容易被忽略的是：同一 Kind 下，Value 的可操作性可能完全不同——比如 reflect.String 和 reflect.Slice 都能 Len()，但前者不可改，后者只有可寻址时才能 SetIndex()。Kind() 只告诉你“它是什么”，不保证“你能对它做什么”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
