Kind判断的是值的底层类型大类，如reflect.Int、reflect.Struct等共约20种轻量枚举，不区分命名类型细节；Type则精确标识完整类型信息，含包名、字段、方法等。
Kind到底在判断什么？——不是“叫什么”，而是“像什么”
Kind回答的是：“这个值在 Go 底层属于哪一大类？” 它不关心你定义的 type UserID int 还是 type Score uint32，只看它们底层是不是整数——所以两者 Kind() 都是 reflect.Int。这就像区分“哺乳动物”和“爬行动物”，而不是“金毛犬”或“中华田园犬”。
- 它是个轻量枚举（
reflect.Int、reflect.Struct、reflect.Slice等共约 20 种），不携带字段名、方法、tag 或包路径 - 适合做泛型式分支：比如统一处理所有
slice，不管它是[]string还是[]*User - 比
reflect.Type更鲁棒——Type相等需完全一致（含包名、定义位置），而Kind只要底层形态相同就匹配
什么时候必须用 Type，而不是 Kind？——精确识别命名类型
当你需要确认“这真是 UserID 类型，不是随便一个 int”时，Kind 就会失效。常见场景包括：
- 判断变量是否为某个自定义类型：
t == reflect.TypeOf(UserID(0))✅；t.Kind() == reflect.Int❌（会把所有整型都判成 true） - 获取结构体字段名：
t.Field(0).Name必须通过reflect.Type调用，Kind没有字段信息 - 打印可读类型名：
t.String()返回"main.User"，而t.Kind()只返回struct - 检查方法是否存在：
t.MethodByName("Save")依赖完整类型信息，Kind无法支撑
指针、nil 和 Elem() —— 最容易 panic 的三个坑
对指针调用 reflect.TypeOf(&x).Kind() 得到的是 reflect.Ptr，不是它指向的类型。若直接拿这个 Kind 做 switch 判断，就会跳过 struct 分支，导致逻辑错乱甚至 panic。
- 处理指针前，先用
t.Elem()解引用（但要确保t.Kind() == reflect.Ptr） - 对
nil接口调用reflect.TypeOf(nil)返回nil，此时调用.Kind()会 panic；应先用reflect.ValueOf(v).IsValid()守护 - 对
reflect.Value调用.Interface()前，务必确认v.CanInterface()，否则未导出字段会 panic：“cannot interface with unexported field”
典型误用：把 Kind 当 Type 比较
这是反射新手最常掉的坑，现象是类型判断永远成功或永远失败：
立即学习“go语言免费学习笔记（深入）”；
type MyInt int
func isMyInt(v interface{}) bool {
t := reflect.TypeOf(v)
return t.Kind() == reflect.TypeOf(MyInt(0)).Kind() // ❌ 总是 true（因为都是 int）
}
真正该写的是：
return t == reflect.TypeOf(MyInt(0)) // ✅ 只有 MyInt 类型才匹配
记住：每次写反射前，下意识问自己一句——我是在区分“车”（Kind）还是“这辆红色丰田卡罗拉”（Type）？漏掉这一问，后面十行代码可能都在修同一个 panic。
