type NewName = OldType 是类型别名，与原类型完全等价，共享方法集、赋值兼容性及底层布局；type NewName OldType 是新类型，独立命名、需显式转换、可定义方法且反射可见。
Go 里用 type NewName = OldType 定义的类型别名，不是“换了个名字而已”，而是明确告诉编译器“我想要原类型的全部行为，包括方法、赋值兼容性、底层内存布局——不加任何修饰”。
为什么 type UserID = int 能直接传给 func f(x int)，但 type UserID int 就不行？
前者是类型别名（alias），后者是新类型（defined type）。Go 规范规定：只有别名与原类型完全等价，才能在函数调用、赋值、类型断言中自由互换；而新类型必须显式转换，比如 int(uid)。这背后不是语法糖，是类型系统对语义的强制区分。
-
type UserID = int：UserID和int共享同一套方法集（空）、同一底层表示、可互相赋值 -
type UserID int：UserID是独立命名类型，哪怕没加任何方法，也和int不兼容 - 错误示例：
var x UserID = 42; fmt.Println(x + 1)在别名下合法，在新类型下报错：invalid operation: x + 1 (mismatched types UserID and int)
type MyChan = chan int 和 type MyChan chan int 在通道方向使用上表现一致吗？
不一致。方向性（chan<- int、<-chan int）只作用于未命名通道类型；一旦你用 type 声明新类型（无等号），它就变成具名类型，方向约束会固化下来；而带等号的别名只是“贴标签”，不改变方向可变性。
-
type Ch = chan int：仍是双向通道别名，可安全转成chan<- int或<-chan int（只要上下文允许） -
type Ch chan int：是具名双向通道类型，不能直接赋给chan<- int参数——因为两者都是具名类型，且方向不匹配，违反 Go 的可赋值性规则 - 典型报错：
cannot use make(Ch) (value of type Ch) as type chan<- int in argument to send
什么时候该用别名（=），什么时候该用新类型（无 =）？
看你要不要“语义隔离”。别名用于提升可读性但不改变契约；新类型用于建立边界、防止误用、预留方法扩展空间。
立即学习“go语言免费学习笔记（深入）”；
- 用别名：
type Email = string、type Timestamp = int64——你只是想让变量名更清晰，仍希望它能像原始类型一样参与所有运算和接口实现 - 用新类型：
type Email string、type UserID int——你准备加验证逻辑、自定义String()、或未来可能绑定方法；同时也主动切断与原始类型的隐式兼容，避免传错参数 - 坑点：别名无法添加方法；新类型可以，但一旦加了方法，就不能再和原始类型互换（即使没用等号）
最易被忽略的是：类型别名的零开销不是靠编译器优化出来的，而是语言规范硬性保证的——它根本不会生成新类型描述符，连 reflect.TypeOf 都看不出区别。这意味着你在做静态分析、类型检查或泛型推导时，别名会自动归一化为底层类型，而新类型始终保留其独立身份。
