reflect.kind 无法区分类型别名与原类型，因二者底层 kind 相同（如均为 reflect.int），区别仅体现在 name()、pkgpath() 和 underlying() 等方法上。
Go 语言中没有“类型别名”在反射层面的独立表示——reflect.Kind 不会区分 type MyInt int 和原生 int，它们的 Kind 完全一致，都是 reflect.Int。
为什么 reflect.Kind 看不到别名？
Go 的类型别名（type MyInt = int）和类型定义（type MyInt int）在底层编译后，对反射系统来说是“透明”的：前者完全等价于原类型，后者虽是新类型但 Kind 仍继承基础类别。反射只暴露运行时可操作的底层分类（如 Int、Struct、Ptr），不保留源码级命名信息。
-
type MyInt = int→reflect.TypeOf(MyInt(0)).Kind() == reflect.Int -
type MyInt int→ 同样返回reflect.Int；区别仅在.Name()和.PkgPath()上 - 想靠
Kind判断是否为别名？行不通——它根本不记录这个语义
那怎么知道一个类型是不是别名？
只能靠 reflect.Type.Name() + .PkgPath() 组合判断是否为空（即未导出或未命名），再结合源码约定或外部元数据。但注意：Name() 对别名返回空字符串，对具名类型（如 type Foo struct{}）才返回 "Foo"；而 PkgPath() 对非导出类型也为空。
- 如果
t.Name() == "" && t.PkgPath() != ""→ 很可能是别名（如type Buf = []byte） - 如果
t.Name() == "" && t.PkgPath() == ""→ 可能是匿名结构体、函数签名或内建类型别名（如type Handler = func(http.ResponseWriter, *http.Request)） - 没有 100% 可靠的纯反射判定方式；真实项目中建议用
//go:generate或go:embed配合类型清单做白名单校验
别名 vs 类型定义：反射行为差异在哪？
关键差异不在 Kind，而在 reflect.Type 的标识性方法：
-
t.String()：别名返回"main.MyInt"（若定义在 main 包），类型定义也类似，但语义不同 -
t.Underlying()：对别名返回其等价类型（如int），对类型定义则返回自身（MyInt） -
t.AssignableTo(other)：别名与原类型完全可互赋值；类型定义默认不可（除非显式实现接口或使用指针）
示例：
type MyInt = int type YourInt int var a MyInt = 42 var b YourInt = 99 fmt.Println(reflect.TypeOf(a).Underlying()) // int fmt.Println(reflect.TypeOf(b).Underlying()) // YourInt（不是 int）
真正容易被忽略的是：别名没有自己的方法集，也不参与接口实现判定——所有反射操作最终都降级到其底层类型。如果你在写泛型约束或动态调用时依赖类型名做路由，别名会悄无声息地“消失”。别指望 Kind 告诉你它是谁，它只告诉你它“像什么”。
