该用 reflect.kind 时是做泛型逻辑（如序列化、日志）只关注“形状”而非“名字”，如判切片、解指针、统一处理自定义整数；必须用 reflect.type 时是需精确识别命名类型，如区分自定义错误、获取字段名或方法。
什么时候该用 reflect.Kind 做类型分支
做泛型式逻辑（比如序列化、日志打印、通用遍历）时，只看“它长得像什么”，不关心“它叫什么”。reflect.Kind 就是为此而生的底层分类枚举——reflect.Int、reflect.Struct、reflect.Slice 这些值稳定、轻量、不随自定义类型变化。
- 对任意切片统一取长度：
v.Kind() == reflect.Slice就够了，不用管它是[]string还是[]*User - 解包指针：先判
v.Kind() == reflect.Ptr，再调v.Elem()，之后才看v.Elem().Kind()是不是struct或int - 避免误匹配：自定义类型
type MyInt int和原生int的Kind都是reflect.Int，但你本来就想把它们当整数统一处理——这正是Kind的设计意图 - 别直接拿
reflect.TypeOf(v).Kind()和某个reflect.Type对象比：比如写成t.Kind() == reflect.TypeOf(MyInt(0))会编译失败，因为右边是Type，左边是Kind（int类型值）
什么时候必须用 reflect.Type 判断具体类型
当你需要区分“这辆红色丰田卡罗拉”和“那辆蓝色本田思域”，也就是要精确识别命名类型本身时，reflect.Type 不可替代。它的 == 比较是类型级的全等，连包路径都算在内。
- 判断是否为某个自定义错误类型：
t == reflect.TypeOf(&MyError{})，而不是t.Kind() == reflect.Ptr（后者会把所有指针都抓进来） - 获取结构体字段名：
t.Field(0).Name只能通过Type调用；Kind没有字段信息 - 检查方法是否存在：
t.MethodByName("Save")返回的是reflect.Method，依赖完整类型元数据 -
Type.Name()只对包级具名类型返回非空字符串，匿名结构体或函数返回空；这是识别“有没有正式名字”的唯一方式 - 注意：
reflect.TypeOf(&x).Kind()是reflect.Ptr，但你想看x本身的类型？得先.Elem()，否则.Name()会返回空
nil 接口和未初始化值的反射陷阱
对 nil 接口变量调用 reflect.TypeOf(nil) 返回 nil，此时再调 .Kind() 会 panic；同理，reflect.ValueOf(nil) 得到的 Value 是无效的，.Type() 也返回 nil。
- 安全做法：先用
reflect.ValueOf(v).IsValid()守护，再访问.Type()或.Kind() - 常见错误现象：
panic: reflect: call of reflect.Value.Kind on zero Value—— 就是忘了IsValid()检查 - 接口 nil 和值 nil 不同：传入
var x interface{}（未赋值），reflect.ValueOf(x)是有效但IsNil()为 true 的；而var x *int再传进去，reflect.ValueOf(x)是IsValid()且IsNil()都为 true
自定义类型 vs 底层类型：为什么 Kind 总是“降级”
Kind 永远返回 Go 运行时内部的 20 多个基础分类之一，它剥离了所有命名信息，只保留最简“形状”。所以 type UserID int、type Code string、type Status bool 的 Kind 分别是 reflect.Int、reflect.String、reflect.Bool，而非它们的名字。
立即学习“go语言免费学习笔记（深入）”；
- 这是有意为之的设计：让泛型逻辑不被类型爆炸搞垮。你写一个通用 JSON 序列化器，不需要为每个
type XXX int单独写 case - 但这也意味着：想靠
Kind区分UserID和OrderID（两者都是int底层）是不可能的——必须用Type比较，或加额外标签/字段 - 容易踩的坑：
reflect.TypeOf(MyInt(0)).Kind() == reflect.TypeOf(int(0)).Kind()永远为 true，但你要的其实是“是不是MyInt类型”，这时候必须用==比较两个Type对象
