Go类型别名（type T = U）表示T与U在编译器中完全等价、不可区分；缺等号则为全新类型；它不拥有独立方法集，无法添加方法，但继承原类型方法，且零运行时开销。
type T = U 表示 T 和 U 是同一个类型，不是“类似”，不是“兼容”，而是**编译器眼里完全不可区分的同一实体**——这是理解 Go 类型别名最核心的一句话。
怎么写、怎么用：语法就一个等号，但错一点就变类型定义
类型别名必须带 =，缺了就是全新类型：
-
type HandlerFunc = func(http.ResponseWriter, *http.Request) error✅ 别名，和原函数类型完全互换 -
type HandlerFunc func(http.ResponseWriter, *http.Request) error❌ 定义，新类型，不能直接传给期望原函数类型的参数
常见错误：复制粘贴时漏掉 =，结果函数签名看着一样，却报 cannot use … as … value in argument。这类错误不提示“少等号”，只报类型不匹配，容易卡住。
为什么用它：不是为了炫技，而是解决三个真实痛点
类型别名在工程中真正起作用的场景很具体：
-
包迁移过渡：比如把
github.com/org/pkg/v2.User拆出来，旧包里加type User = v2.User，依赖旧路径的代码零修改照跑 -
API 版本兼容：老接口参数叫
ReqV1，新版统一为Request，就写type ReqV1 = Request，既保兼容又不重复实现 -
泛型嵌套缩写：像
map[string]map[int][]*struct{ X, Y float64 }这种，定义type GeoMap = map[string]map[int][]*struct{ X, Y float64 }后，字段声明、函数参数、文档都立刻可读
容易被忽略的关键限制：它没有自己的方法集，也不能加方法
别名只是“换个名字喊”，不是“另立门户”：
- 你不能对
type PortNumber = uint16写func (p PortNumber) IsValid() bool { ... }—— 编译失败，因为PortNumber没有方法集，它就是uint16 - 如果原类型（如
uint16）本身没方法，那别名也啥都没有；如果原类型是带方法的自定义类型（如type MyInt int加了方法），那别名会继承这些方法 —— 但注意，这是继承原类型的方法，不是别名自己定义的 - JSON 序列化行为完全一致，不需要额外加
json:tag；reflect.TypeOf(x).Name()对别名返回空字符串（因为它没名字），而原类型可能有
和类型定义（type T U）混用时最危险的错觉
很多人以为 type MyString = string 和 type MyString string 只差一个等号，语义差不多。其实天壤之别：
type Alias = string
type Def string
func f(s string) {}
func g(s Alias) {}
func h(s Def) {}
var a Alias = "hello"
var d Def = "world"
f(a) // ✅ OK：Alias 就是 string
g(a) // ✅ OK：参数类型匹配
h(a) // ❌ compile error：Def ≠ string，哪怕 a 是 string 字面量也不行
f(d) // ❌ compile error：Def 不是 string，不能隐式转
这种差异在大型项目中一旦误用，会导致大量函数调用中断、接口实现失败、mock 测试崩掉——尤其当团队成员对 = 是否存在缺乏敏感时，问题会悄无声息地扩散。
