type T = U 不能加方法，因为它是编译期擦除的别名，运行时等同于U，Go只允许为包内声明的新类型（如type T U）定义方法；别名仅用于语义复用或兼容过渡，不提供类型隔离。
type T = U 为什么不能加方法
因为 type T = U 在编译期就完全擦除，运行时不存在 T 这个类型——它只是源码里的“笔名”，reflect.TypeOf() 返回的永远是 U，调试器里也看不到 T。Go 规定方法只能定义在包内声明的**新类型**上，而别名不是新类型，所以 func (t T) Method() 会直接报错：cannot define new methods on non-local type T。
- 常见错误：写
type Status = string后想加IsValid()，编译失败 - 正确做法：改用
type Status string，再定义方法 - 别名的用途不是封装行为，而是语义复用或兼容过渡
type T U 和 type T = U 在接口赋值时表现不同
接口场景最容易产生错觉。比如 type Res http.ResponseWriter 看似能接 *http.response，但那是因为它满足接口方法集；而 type Res = http.ResponseWriter 才是真正等价——前者是新类型，后者才是原类型。
-
type Res http.ResponseWriter：可加方法，但加完就破坏接口兼容性（*http.response不再能隐式赋值） -
type Res = http.ResponseWriter：零成本替换，传参、断言、赋值全畅通，且无法加方法 - 结构体不适用这套逻辑：
type Res response.Response（假设response.Response是 struct）永远无法隐式赋值，必须显式转换Res(r)
泛型约束里 ~int 能匹配 type T int，但不匹配 type T = int
泛型约束中的底层类型操作符 ~ 只对**新类型**有效。它表示“底层为 int 的任何自定义类型”，所以 type MyInt int 符合 ~int，但 type MyInt = int 不符合——后者根本不是“新类型”，它就是 int 本身。
- 如果你写
type Number interface{ ~int | ~float64 }，那么MyInt int可以作为参数传入，MyInt = int就不行（除非你显式用int） - 别名在泛型中只起命名简化作用，比如
type EventChan[T any] = chan T，不影响约束逻辑 - 混淆这两者会导致泛型函数调用时静默失败或编译报错
什么时候该用别名，什么时候必须用新类型
核心判断标准就一条：你是否需要类型系统层面的隔离或行为封装。需要？用 type T U；只需要换个名字、保持完全兼容？用 type T = U。
立即学习“go语言免费学习笔记（深入）”；
- 用别名：
type HandlerFunc = func(http.ResponseWriter, *http.Request)（简化签名）、type User = v2.User（跨版本迁移） - 用新类型：
type Password string（防误用）、type DurationMs int64（单位隔离）、type UserID int64（控制构造） - 最常被忽略的点：别名不会出现在 JSON 序列化/反序列化行为中——
type Status = int的json.Marshal行为和int完全一致；而type Status int可以实现自己的MarshalJSON()
