reflect.TypeOf 返回变量的实际类型，Name() 仅对命名类型非空，Kind() 才可靠判断基础类别；结构体私有字段不可见，需用 Elem()、Tag 等配合；反射性能低且易 panic，应缓存 Type 并先判空。
如何用 reflect.TypeOf 获取变量的底层类型
直接调用 reflect.TypeOf 返回的是 reflect.Type 接口，它描述的是接口背后的**实际类型**（不是接口类型本身）。比如对一个 *string 变量调用，返回的是指向 string 的指针类型，而非 string。
常见误区是以为 reflect.TypeOf(x).Name() 总能拿到名字——其实只有命名类型（如 type MyInt int）才返回非空字符串；内置类型（int、string）或匿名结构体、切片、映射等，Name() 都返回空串。
- 用
reflect.TypeOf(x).Kind()判断基础类别（reflect.Struct、reflect.Slice等）更可靠 - 需要完整类型描述时，用
reflect.TypeOf(x).String()，它返回类似"*main.User"或"[]int"的字符串 - 若变量是接口值（如
interface{}），reflect.TypeOf返回的是其动态值的类型，不是接口类型
为什么 reflect.Type.Name() 经常返回空字符串
Name() 只返回该类型的**未限定名称**，且仅当类型在包一级被显式声明（即有 type 关键字定义）时才有值。例如：
type Person struct{ Name string }
var p Person
fmt.Println(reflect.TypeOf(p).Name()) // "Person"
var s []string
fmt.Println(reflect.TypeOf(s).Name()) // ""（因为 []string 是复合类型，无名字）
同理，函数类型、通道、数组长度不固定等，Name() 均为空。这时候必须依赖 Kind() + String() 组合判断。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 想区分
[]int和[]string？看reflect.TypeOf(s).Elem().Name()（对切片取元素类型再查名） - 嵌套类型如
*Person：先用reflect.TypeOf(ptr).Elem()解引用，再调Name() - 注意
reflect.Type.PkgPath()可获取包路径，用于判断是否为导出类型或跨包类型
获取结构体字段名和类型信息的正确姿势
对结构体类型，reflect.Type 提供 NumField() 和 Field(i) 方法。但要注意：只有**导出字段**（首字母大写）才能通过反射读取；私有字段会存在，但 Field(i).Name 为空，且无法访问其值。
type User struct {
ID int `json:"id"`
name string `json:"-"` // 私有字段，反射不可见
}
t := reflect.TypeOf(User{})
fmt.Println(t.NumField()) // 输出 1，不是 2
fmt.Println(t.Field(0).Name) // "ID"
fmt.Println(t.Field(0).Tag.Get("json")) // "id"
- 用
t.Field(i).Anonymous判断是否为内嵌字段 -
t.Field(i).Type.Kind()比t.Field(i).Type.Name()更稳定，尤其对基础类型字段 - 字段标签（tag）要用
Field(i).Tag.Get("key")安全提取，避免 panic
反射获取类型名时容易忽略的性能与安全点
反射本身开销大，且绕过编译期类型检查。在高频路径（如 HTTP 中间件、序列化循环）中反复调用 reflect.TypeOf 会显著拖慢性能。更糟的是，如果传入 nil 接口值，reflect.TypeOf(nil) 返回 nil，直接调方法会 panic。
- 缓存
reflect.Type结果：对固定类型（如已知的 struct 类型），在 init 或变量初始化时获取并复用 - 判空习惯：用
if t := reflect.TypeOf(v); t != nil { ... }，而不是直接链式调用 - 避免对 map/slice 元素类型反复反射：先取
t.Elem()或t.Key()缓存，别每次循环都reflect.TypeOf(item)
类型名称不是字符串拼接出来的标识符，而是运行时类型系统的视图；依赖 Name() 的逻辑，在面对泛型实例化、接口断言或复杂嵌套时极易失效。真正健壮的反射代码，永远以 Kind() 为第一判断依据，Name() 和 PkgPath() 仅作辅助。
