类型别名（type T = U）与自定义类型（type T U）在编译期本质不同：前者共享U的runtime._type元数据，后者生成独立元数据；别名不可添加方法、赋值无需转换、反射显示原类型，而自定义类型可定义方法、赋值需显式转换、反射显示新类型名。
类型别名和自定义类型在编译期就不是一回事
Go 的类型系统在编译时严格区分二者：类型别名（type MyInt = int）与原类型共享同一份 runtime._type 元数据；而自定义类型（type MyInt int）会生成独立的元数据，哪怕底层完全一样。这意味着：
– MyInt 和 int 在类型断言、接口实现、反射 reflect.TypeOf() 中表现完全不同；
– 类型别名不会出现在编译后的符号表中，调试器里也看不到它——它只是源码层面的“笔名”。
赋值和方法绑定是验证差异最直接的方式
写两行代码就能立刻看出区别：
type NewInt int type MyInt = intfunc (n NewInt) Double() int { return int(n) * 2 } // func (n MyInt) Double() int { ... } // 编译错误：不能为非定义类型添加方法
关键点：
-
NewInt可以自由定义方法，因为它是一个新类型；MyInt不行，它就是int，而 Go 禁止给内置类型（或其别名）加方法 -
var a NewInt = 5; var b int = a→ 报错：类型不匹配，需显式转换int(a) -
var x MyInt = 5; var y int = x→ 完全合法，无需转换 - 用
fmt.Printf("%T", x)打印，输出是int；而%T打印a输出是main.NewInt
什么时候该用类型别名，什么时候必须用自定义类型
选错会导致后续维护成本飙升，甚至埋下隐性 bug：
立即学习“go语言免费学习笔记（深入）”；
- 用
type StatusCode = int：适合做语义增强，比如 HTTP 状态码，你只想要可读名，不打算封装行为，也不需要隔离类型系统 —— 这时别名零开销、无缝兼容所有int操作 - 用
type StatusCode int：适合要强约束的场景，比如禁止把任意int当作状态码传入函数，或想为它实现String()、MarshalJSON()等专属逻辑 - 泛型约束中常混用：如
type Number interface{ ~int | ~float64 }，这里的~int表示“底层为 int 的任何类型”，所以它能同时接受int和type MyInt int，但不接受type MyInt = int（因为后者不是“新类型”，只是int自身）
别名不是“语法糖”，它是类型系统的正式成员
很多人误以为类型别名只是写起来方便，其实它被深度集成进 Go 的类型推导和泛型机制中。例如：
type HandlerMap = map[string]func() error type Middleware = func(http.Handler) http.Handler// 这些别名可直接用于泛型参数、接口定义、函数签名，且不增加任何运行时成本 func Register(h HandlerMap) { / ... / }
但要注意一个坑：
– 如果你在多个包里都写了 type MyConfig = struct{...}，它们彼此之间仍是同一类型，可直接赋值；
– 而如果写成 type MyConfig struct{...}，哪怕结构体字段一模一样，不同包下的 MyConfig 也是互不兼容的两个类型。
真正容易被忽略的是：类型别名让「类型等价性」变得透明，而自定义类型让「类型隔离性」成为默认行为。选哪个，本质是在问：你希望这个名字代表“我是谁”，还是“我叫什么”。
