解析Golang反射中的Kind与Type区别 Go语言底层类型类别判定-Golang-PHP中文网

kind和type不同：kind表示运行时底层类别（如ptr、slice），共27种且稳定；type表示完整类型描述（如*bytes.buffer），依赖定义方式。判断类型分支应用kind，精确匹配才用type。

解析golang反射中的kind与type区别 go语言底层类型类别判定

反射里 `Kind` 和 `Type` 不是一个东西

很多人一上来就用 reflect.TypeOf(x).Name() 想判断类型，结果 struct 字段返回空字符串、interface{} 返回 ""、指针没名字——不是 API 坏了，是搞混了 Type（完整类型描述）和 Kind（底层类别）。Type 回答“它是什么类型”，Kind 回答“它在运行时算哪一类基本形态”。比如 *bytes.Buffer 的 Type 是 *bytes.Buffer，但 Kind 是 Ptr；[]int 的 Type 是 []int，Kind 是 Slice。

`Kind` 才该用于分支判断，`Type` 适合做精确匹配

写反射逻辑时，绝大多数类型分支都该基于 Kind，而不是 Type.String() 或 Name()。因为 Kind 稳定、有限（只有 27 种）、不随包路径或别名变化。而 Type 名字依赖定义方式：自定义类型 type MyInt int 的 Name() 是 "MyInt"，但 Kind() 还是 Int；匿名结构体连 Name() 都是空。

用 v.Kind() == reflect.Struct 判断是否能遍历字段，别用 strings.Contains(t.String(), "struct")
序列化/解序列化库内部用 Kind 分流：Ptr 先解引用，Slice 走循环，Map 走键值对遍历
需要精确识别用户定义类型（比如只处理 type UserID int）才用 t.Name() == "UserID" && t.PkgPath() == "myapp/user"

`Kind` 会穿透指针和接口，`Type` 不会自动展开

这是最常踩的坑：拿到一个 interface{} 或指针后，直接调 reflect.TypeOf 得到的是包装类型，不是你想要的“实际承载的类型”。Kind 在多数情况下会帮你“看穿”一层间接性，但得主动调用 Elem() 或 Indirect()。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

var x *string; reflect.ValueOf(x).Kind() → Ptr，不是 String；要得到指向的类型，得 reflect.ValueOf(x).Elem().Kind()
var i interface{} = "hello"; reflect.TypeOf(i).Kind() → Interface，不是 String；必须先 reflect.ValueOf(i).Elem().Kind()（且确保 i 非 nil）
安全做法：用 reflect.Indirect(reflect.ValueOf(x)) 自动解多层指针，再取 Kind()

struct 字段的 `Type` 和 `Kind` 容易误读

遍历 struct 字段时，Field(i).Type 返回字段声明的完整类型（比如 map[string][]*User），而 Field(i).Type.Kind() 是 Map。但注意：嵌套类型里的 Kind 不会递归展开，map[string][]*User 的 Kind 是 Map，不是 String 或 Ptr。

想判断字段是不是切片？看 field.Type.Kind() == reflect.Slice，不是 strings.Contains(field.Type.String(), "[]")
想获取切片元素类型？用 field.Type.Elem()，不是 field.Type.Name()
字段是 json.RawMessage？它的 Kind 是 Struct（因为底层是 []byte 别名 + 方法），但 Type.String() 是 "json.RawMessage" —— 这时候得结合 PkgPath() 和 Name() 才能准确识别