类型别名（type T = U）与类型定义（type T U）语义不同：前者使T与U完全等价，后者创建全新独立类型；别名仅适用于重构场景且需Go 1.9+，不可添加方法，接口实现自动继承；类型定义则支持方法、强类型安全，但无隐式转换。
别名（type t = u）和定义（type t u）不是写法差别，而是类型系统级别的语义分叉：前者让 t 和 u 在编译器眼里是同一个类型；后者则生成一个全新、独立的类型。
什么时候用 type T = U 才算真正需要别名
只在重构大型代码库时才值得动用别名语法。比如要把 time.Time 替换成自研的 MyTime 类型，但又不能改所有已有调用点——这时先加 type Time = MyTime，让旧代码继续通过编译，后续再逐步替换。
- 必须是 Go 1.9+，低版本不识别
=语法，会直接报错syntax error: unexpected = - 别名不能带方法：一旦你给
type T = U加了方法，Go 编译器会拒绝，因为别名不允许扩展行为 - 接口实现自动继承：如果
U实现了某个接口，T也天然满足，无需额外声明 - 底层结构、可比较性、可赋值性全部一致，连
reflect.TypeOf都返回相同结果
为什么 type T U 不是“换个名字”而是“造个新类型”
type T U 是最常用写法，但它创建的是一个全新类型，哪怕 U 是 int 或 string 这种基础类型。它和原类型之间没有隐式转换，也不能直接比较或赋值。
- 可以自由定义方法：比如
type MyInt int后，你能写func (m MyInt) Double() MyInt { return m * 2 }，而int本身无法拥有这个方法 - 类型安全屏障：
MyInt(42)不能直接传给接收int的函数，必须显式转成int(42)，防止误用 - 即使
U是接口，type T U也不是别名——它只是声明T满足该接口，但T仍是独立类型，不能和U直接互换（除非你用的是type T = U） - struct、map、slice 等复合类型右侧出现时，
type T U必然创建新类型，不存在“别名”歧义
常见错误：把 type Res http.ResponseWriter 当成别名
很多人看到 type Res http.ResponseWriter 就以为 Res 是 http.ResponseWriter 的别名，其实它是类型定义，只是碰巧能用，因为 http.ResponseWriter 是接口。真正起作用的是接口的“鸭子类型”规则，不是类型等价。
- 错误现象：
var r Res; r.Write([]byte("ok"))能过，就以为Res和http.ResponseWriter可互换；但一旦你给Res加了个方法，比如func (r Res) Status() int，它就再也无法赋值给http.ResponseWriter类型变量了 - 正确做法：如果真要保持完全兼容，得写
type Res = http.ResponseWriter（Go 1.9+） - 兼容性陷阱：旧项目里大量用
type T U模拟别名，升级到依赖别名语义的工具链时，会突然编译失败
最容易被忽略的一点：类型别名不是“语法糖”，它是 Go 类型系统中一条明确的语义路径。一旦选错，轻则多写几十行转换代码，重则导致接口实现断裂、泛型约束不匹配、反射行为异常——这些都不是运行时能发现的问题，而是编译期静默失败或报错晦涩难解。
