reflect.Kind 是描述值基础类别的底层枚举，如 reflect.Struct、reflect.Slice；它不反映具体类型名，也不区分 type MyInt int 和 int（二者 Kind 均为 reflect.Int）。
reflect.Kind 是什么，不是什么
reflect.Kind 是一个底层枚举，只描述值的“基础类别”，比如 reflect.Struct、reflect.Slice、reflect.Ptr。它不关心具体类型名，也不区分 type MyInt int 和 int —— 两者 Kind() 都是 reflect.Int。
常见误用是拿 Kind 当类型名做字符串比较：v.Kind() == reflect.Struct ✅，但 v.Kind().String() == "Struct" ❌（Kind 没有 String() 方法）；更糟的是写成 v.Kind() == "struct"，编译直接报错。
分支判断必须用 == 直接比对 reflect.Kind 常量，这是唯一安全方式。
switch v.Kind() 必须覆盖所有可能分支
Go 的 reflect.Kind 有 27 个有效值（截至 2026 年），包括 reflect.Invalid、reflect.UnsafePointer 等冷门项。如果你只写 case reflect.Struct:、case reflect.Slice:，漏掉 default 或 case reflect.Invalid:，遇到 nil 接口或未初始化值时会 panic。
立即学习“go语言免费学习笔记（深入）”；
推荐写法：
switch v.Kind() {
case reflect.Struct:
// 处理结构体
case reflect.Slice, reflect.Array:
// 共享逻辑
case reflect.Ptr:
if !v.IsNil() {
handlePtr(v.Elem())
}
case reflect.Invalid:
// 显式处理：比如日志告警或跳过
default:
// 不支持的 kind，避免静默失败
}
尤其注意：reflect.ValueOf(nil) 返回的 v.Kind() 是 reflect.Invalid，不是 reflect.Ptr。
Kind 判断顺序影响可读性与性能
虽然 Go 编译器对 switch 有优化，但实际中 reflect.Kind 分支常按使用频率排序更合理。比如 JSON 解析场景，reflect.Struct、reflect.Map、reflect.Slice 出现最多，应前置；reflect.Chan、reflect.Func 很少出现，可后置或归入 default。
另一个关键点：指针必须先解引用再判断底层 Kind。错误写法：if v.Kind() == reflect.Ptr { v.Field(0) } → panic，因为 Field() 只对 Struct 有效。正确流程是：
- 先确认
v.Kind() == reflect.Ptr - 再检查
!v.IsNil() - 最后调用
v.Elem().Kind()判断真实类型
把 v.Elem().Kind() 直接塞进 switch 里会导致嵌套过深，建议提前 if v.Kind() == reflect.Ptr { v = v.Elem() } 统一降级处理。
Kind 与 Type 混用导致的 runtime panic
最典型的坑：在 v.Kind() == reflect.Struct 分支里，直接调用 v.Type().Name() 期望拿到结构体名，结果返回空字符串 —— 因为匿名结构体、内建类型或非导出结构体的 Name() 都为空。
此时该用 v.Type().String() 或继续依赖 v.Kind() 判断行为，而不是强行取名。类似地，v.NumField() 要求 v.Kind() == reflect.Struct，但若 v 实际是 reflect.Ptr 且未 Elem()，就会 panic。
所以每个反射操作前都得校验 Kind，不能靠“看起来像”就硬上。比如遍历 map，必须先 v.Kind() == reflect.Map，再 v.MapKeys()；对 slice 调 v.Len() 前也一样。
复杂点在于嵌套结构：一个 **[]map[string][]int 类型，需要连续三次 Kind() 判断和 Elem() 解包，中间任何一步漏判都会崩。别省那几行 if。
