type关键字定义的是新类型而非别名，除非显式使用“=”（go 1.9+）；无“=”时如type t int创建独立类型，具语义隔离、方法需重定义、接口不自动继承；有“=”时如type t = int才是完全等价别名。
type 关键字到底在定义什么：别名还是新类型？
Go 里 type 有两种本质不同的用法，区别不在语法，而在是否带底层类型（underlying type）的“断连”。不加 Struct、Interface、func 等复合结构时，type T1 T2 是别名；只要包了一层，比如 type T1 struct{ T2 } 或 type T1 int，就是全新类型。这个断连决定方法能否复用、值能否直接赋值、接口实现是否自动继承。
常见错误现象：type MyInt int 后，直接把 MyInt 当 int 传给只接受 int 的函数，编译报错 cannot use myIntValue (type MyInt) as type int —— 这不是 bug，是设计使然。
- 别名写法：
type MyInt = int（Go 1.9+），此时MyInt和int完全等价，可互换 - 新类型写法：
type MyInt int，底层是int，但类型系统视其为独立类型 - 别名不产生新方法集；新类型默认无任何方法，哪怕原类型有方法
什么时候必须用新类型而不是别名
核心场景就一个：需要语义隔离或强制类型检查。比如 type UserID int 和 type OrderID int，即使都是 int，也不允许混用 —— 编译器会拦住你把 UserID 直接当 OrderID 传。
性能上没差别，底层存储完全一致；但兼容性要注意：新类型不会自动实现原类型的接口。例如 type MyString string 后，MyString 不再自动满足 fmt.Stringer（除非你显式实现）。
立即学习“go语言免费学习笔记（深入）”；
- API 参数/返回值需要明确业务含义时，选新类型
- 想复用原类型所有方法和接口实现，且不需要类型安全隔离，用别名（
=） - 导出类型名首字母大写，但底层类型是未导出的（如
type t int），会导致新类型无法被外部包使用 —— 别这么干
方法绑定只认新类型，别名没法“借”方法
这是最容易踩的坑：以为 type MyInt int 就能直接用 int 的所有行为，结果调方法时报 undefined。因为方法是绑定在具体类型上的，int 有方法不等于 MyInt 有。
示例：type Celsius float64，就算 float64 能做四则运算，你也得自己写 func (c Celsius) Add(other Celsius) Celsius 才能调 c.Add(d)。
- 新类型要获得方法，必须显式为它定义（接收者是
MyType或*MyType） - 别名（
type T = U）可以无缝使用U的所有方法，因为它是同一个类型 - 嵌入结构体（如
type MyInt struct{ int }）也不能自动继承int的方法 —— 结构体字段不是类型本身
json / encoding 场景下，别名和新类型表现一样吗？
基本一样，但有个关键例外：如果新类型实现了 UnmarshalJSON 或 MarshalJSON，就会优先进入自定义逻辑；而别名不会触发，它直接走底层类型的默认编解码。这点在调试序列化行为时特别容易忽略。
比如 type Email string 并实现了 UnmarshalJSON 做邮箱格式校验，那 JSON 解析时就会执行校验；但 type Email = string 就不会，永远走 string 的默认逻辑。
- 标准库的
json.Marshal/Unmarshal对新类型和别名都按底层类型处理，除非显式实现接口 -
encoding/gob同理，但注意：gob 会把新类型当作独立类型注册，别名则共享原类型的 gob 类型 ID - 用
reflect.typeof(x).Name()能区分：新类型返回定义名（如"MyInt"），别名返回空字符串（因为没名字）
事情说清了就结束。最常被忽略的是：别名（=）和新类型（无 =）在方法、接口、序列化三处行为差异极大，不能凭直觉混用。