17370845950

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 比较

这是反射新手最常掉的坑，现象是类型判断永远成功或永远失败：

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。