真正的类型别名（type T = U）与原类型完全等价、不可添加方法、无运行时开销；而类型定义（type T U）创建全新类型，可定义专属方法、不兼容原类型。
type alias 无法定义方法
类型别名（type T = U）在 Go 中就是原类型的“另一个名字”，编译器不为它生成独立方法集。哪怕你写了 func (t T) Method()，编译器也会报错：cannot define new methods on non-local type T——因为 T 不是本地新类型，它等价于 U，而方法只能定义在包内声明的自定义类型上。
常见错误现象：cannot define method on type MyInt，但 MyInt 实际是 type MyInt = int，不是 type MyInt int。
- 只有
type MyInt int这种写法才能加func (m MyInt) String() string -
type MyInt = int后，想扩展行为？得靠函数封装，比如func FormatMyInt(i MyInt) string - 重构时若把
type MyInt int改成type MyInt = int，所有已定义的方法会直接失效，且不会报错——它们只是“挂在那里”，永远无法被调用
自定义类型有专属方法集，但不继承原类型方法
type T U（无等号）声明的是全新类型，哪怕 U 是 int 或 string，T 也和 U 方法集完全无关。Go 不自动继承，也不隐式转发。
使用场景：你想封装底层类型并控制行为边界，比如防止误传裸 int 当用户 ID：
-
type UserID int可以定义func (u UserID) Validate() error - 但
UserID(123)不会自动拥有int的任何方法（int本身也没方法） - 如果
U是接口，比如type Res http.ResponseWriter，那Res方法集 =http.ResponseWriter方法集（空），但它是新类型，不能接收实现了该接口的值，除非显式赋值或转换
接口类型上的 type definition 行为特殊
当右边是接口（如 http.ResponseWriter）时，type Res http.ResponseWriter 看似是“新类型”，但它能接收任何满足该接口的值（如 *http.response），因为 Go 允许接口到接口的隐式赋值——前提是方法集一致。
但这不是“继承”，而是接口兼容性规则在起作用：
-
var w http.ResponseWriter = &http.response{}✅ -
var r Res = w✅（因为Res和http.ResponseWriter方法集完全相同） -
var r Res = &http.response{}✅（同上） - 但一旦你给
Res加个方法：func (r Res) Log() {}，上面两行就全报错 ❌
JSON 序列化时方法集不参与，但间接影响行为
json.Marshal 不看方法集，只看字段和结构体标签。所以 type T = U 和 type T U 在纯数据序列化上表现一致。
但容易被忽略的点在于：如果 T 是自定义类型，并且你为它实现了 json.Marshaler 接口，那行为就完全不同了：
-
type MyInt int+func (m MyInt) MarshalJSON() ([]byte, error)→ 走自定义逻辑 -
type MyInt = int→ 没法实现该方法，只能走int默认序列化 - 更隐蔽的是：如果
U本身实现了MarshalJSON（比如某个 struct 类型），那type T = U也能用，但type T U就不能——除非你手动再实现一遍
方法集差异不是语法糖级别的区别，它直接决定你能加什么方法、值能不能互换、接口能否满足、序列化走哪条路径。最常踩的坑，是以为 type Res http.ResponseWriter 和 type Res = http.ResponseWriter 只差一个等号，其实前者能加方法后者不能，前者是新类型后者根本不是类型——它只是个重命名。
