Go反射无法直接识别类型别名，因别名在运行时消失；需结合Name()、PkgPath()和Underlying()间接推断，其中Underlying()最可靠：别名返回等价类型，新类型返回自身。
Go 反射无法直接识别类型别名（type T = U），因为别名在运行时完全消失；它只能通过 Name()、PkgPath() 和 Underlying() 的组合间接推断——但这不是 100% 可靠的判定手段。
reflect.Kind 对别名和定义类型一视同仁
reflect.Kind 返回的是底层分类（如 reflect.Int、reflect.Struct），不携带“是否为别名”的语义。无论是 type MyInt = int 还是 type MyInt int，reflect.TypeOf(MyInt(0)).Kind() 都返回 reflect.Int。
- 别名和新类型共享同一
Kind，这是设计使然：反射面向运行时行为，而别名无运行时开销 - 不能用
Kind判断是否为别名，否则会误判所有具名类型（比如type Status string） - 想区分结构体类型是否为别名？关键看是否含
struct关键字，而非字段是否相同
如何用 Name() + PkgPath() 猜别名
别名在反射中通常表现为 Name() 为空字符串，但 PkgPath() 非空（若定义在非 main 包）；而原生类型（如 int）或未导出匿名类型则两者都为空。
-
type Buf = []byte→t.Name() == "" && t.PkgPath() != ""（较大概率是别名） -
type Handler = func(http.ResponseWriter, *http.Request)→ 同样Name() == ""，但它是函数类型别名，PkgPath()可能为空 -
type MyInt int→t.Name() == "MyInt"，t.PkgPath()是包路径，明确表示它是新类型 - 注意：
t.Name() == ""不等于“一定是别名”，也可能是内建类型别名（如rune）、匿名结构体或闭包
Underlying() 是最实用的区分依据
Underlying() 方法返回类型的底层实现类型，对别名返回其等价类型，对新类型返回自身——这是最稳定、最符合语义的判断方式。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
type MyInt = int→t.Underlying() == reflect.TypeOf(int(0)).Type -
type MyInt int→t.Underlying() == t（即自身） - 可用于泛型约束中做类型归一化：先调
t.Underlying()再比对基础类型 - 但要注意：嵌套别名（如
type A = B; type B = int）会逐层展开，Underlying()最终指向最底层类型
别名上无法调用自定义方法，反射也看不到
类型别名不能定义方法，这是编译器硬限制；反射层面也完全不体现任何方法集差异——NumMethod() 返回的方法数与原类型一致，且所有方法都来自底层类型 U。
-
type ReqID = string→reflect.TypeOf(ReqID("")).NumMethod()返回string的方法数（0），不是 1 -
type ReqID string→ 若你为其定义了Validate()，NumMethod()就会返回 1 - 别名的
Method(i)返回的是string的方法（如len相关的反射信息），不是你“以为加上的”方法 - 别名无法满足需要特定方法集的接口约束，哪怕名字一样、行为一样，泛型也无法推导
真正棘手的地方在于：反射能告诉你“它看起来像什么”，但无法 100% 确认“它是不是别名”。生产环境建议配合代码生成（//go:generate）或白名单配置来规避歧义，而不是依赖运行时反射做关键逻辑分支。
