kind比较比type比较快，因kind是int常量比较，而type涉及接口比较、元数据地址比对和包路径匹配；kind适用于泛型分支，type用于精确类型校验，如自定义错误或grpc消息体。
Kind比较比Type比较快，因为它是int常量比较
直接用 v.Kind() == reflect.String 比用 v.Type() == reflect.TypeOf("") 快得多。前者是两个 int 值比较（reflect.Kind 底层就是 uint），后者要走接口比较、类型元数据地址比对，还涉及包路径字符串匹配。
高频路径比如 JSON 序列化循环、日志字段遍历，如果写成 t.String() == "string" 或 t.Name() == "string"，不仅慢，还会因匿名类型返回空字符串而失效。
-
reflect.Kind是枚举值，稳定、轻量、无内存分配 -
reflect.Type是接口，背后携带包路径、方法集、字段列表等完整元数据 - 缓存
reflect.Type可以减小开销，但首次获取仍比 Kind 重一个数量级
Type比较必须用==，不能用Kind模拟
想确认某个变量是不是 *MyError 类型？只看 v.Kind() == reflect.Ptr 不够——所有指针都满足，包括 *os.File、*http.Request。这时候必须用 v.Type() == reflect.TypeOf((*MyError)(nil)).Elem() 这类精确匹配。
常见错误是试图用 Kind 绕过 Type 比较，比如写 v.Kind() == reflect.Struct && v.Type().Name() == "User"，但 Name() 对匿名结构体返回空，且不校验包路径，实际等于没锁住类型。
- Type 的
==是全等：包路径 + 名字 + 定义方式三者一致才为 true - 自定义错误、ORM 实体、gRPC 消息体这类需强类型语义的场景，绕不开 Type
- 别用
v.Type().String()做判断——它含包路径，不同构建环境可能不稳定
Kind会穿透一层间接性，Type不会自动展开
传入一个 interface{} 包着 *string，reflect.ValueOf(x).Kind() 返回 Interface，不是 Ptr；而 reflect.ValueOf(x).Elem().Kind() 才是 Ptr。这说明 Kind 并不“自动穿透”，只是比 Type 更容易手动解包。
真正省事的是组合用法：reflect.Indirect(reflect.ValueOf(x)).Kind()，它会递归解指针和接口直到非 Ptr/Interface，再取 Kind——但注意，它不处理 nil 接口或未初始化值。
- 安全写法：先
v.IsValid()，再reflect.Indirect(v).Kind() -
reflect.TypeOf(x)永远返回最外层类型，*string就是*string，不会变成string - 想统一处理“能当 slice 用的东西”，用
reflect.Indirect(v).Kind() == reflect.Slice比反复Elem()更稳
真实性能差距在微秒级，但逻辑错位代价远高于时间
单次 Kind() 调用约 2–3 ns，Type() 获取加比较约 50–200 ns，差别看似不大。但线上服务每秒处理数万请求时，错用 Type 做泛型分支会导致 CPU 热点集中在反射路径，GC 压力上升，而更致命的是逻辑误判——比如把 type Status uint8 当普通整数序列化，却漏掉其 String() 方法语义。
最容易被忽略的是：Kind 只告诉你“像什么”，不保证“能干什么”。reflect.String 和 reflect.Slice 都有 Len()，但前者不可改，后者在不可寻址时调 SetIndex() 会 panic。判断完 Kind，还得看 v.CanAddr() 或 v.CanInterface() 才敢操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
