type T = U 是重构时唯一能保持二进制兼容的写法，它不生成新类型元数据，reflect.TypeOf() 返回原类型，JSON/gRPC/数据库行为全不变，而 type T U 会创建全新类型并切断方法集与接口实现。
type T = U 是重构时唯一能保持二进制兼容的写法
当你需要把 pkg/v1.User 平滑迁移到 pkg/v2.User，又不能让所有调用方改 import 或类型名，type User = v2.User 是唯一选择。它不生成新类型元数据，reflect.TypeOf() 返回的仍是 v2.User，JSON 序列化、gRPC 编码、数据库驱动行为全部不变。
常见错误现象：cannot use u (type v1.User) as type v2.User in argument——说明你用了 type User v2.User（新类型），而不是别名。前者必须显式转换 v2.User(u)，后者直接传就行。
- 别名只在编译期存在，运行时完全消失；新类型在 runtime 中有独立
_type结构 - 跨包迁移时，旧包里写
type User = v2.User，新包照常定义type User struct { ... }，调用链零修改 - 泛型约束中若用别名，
type Number = interface{ ~int | ~float64 }可复用，且不影响底层类型方法集
别名不能加方法，这不是缺陷而是设计契约
写 type Email = string 后试图定义 func (e Email) Validate() bool，Go 会报错 cannot define new methods on non-local type。这不是 bug，是语言强制你做语义决策：想封装行为？必须用 type Email string（新类型）；只想换名字？就用 =。
容易踩的坑：误以为别名能“继承”原类型方法。比如 type HandlerFunc = func(http.ResponseWriter, *http.Request)，它确实能传给 http.Handle()，但你不能给它加 WithLogger() 方法——得用新类型 + 匿名字段组合实现。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
type UserID = int64→ 可直接赋值给int64参数，但无法加IsValid() -
type UserID int64→ 必须显式转int64(uid)，但可自由加方法、实现接口 - 调试时看
fmt.Printf("%T", uid)：别名输出int64，新类型输出main.UserID
嵌套泛型和结构体字段里，= 和空格决定一切
泛型容器别名最易出错：写 type EventChan[T any] = chan T 是合法别名；但漏掉等号写成 type EventChan[T any] chan T 就变成新类型，无法直接传 chan string 给它。
结构体字段也一样：type Config = struct{ Port int } 是别名，等价于匿名结构体字面量；而 type Config struct{ Port int } 是新类型，哪怕字段一模一样，也不能和别的同结构 struct 互换。
- 函数类型别名必须带
=：type Middleware = func(http.Handler) http.Handler - 切片/映射/通道别名也需
=：type StringSet = map[string]struct{} - Go 1.9+ 内建类型如
type byte = uint8已全部改用别名语法，这是向后兼容的基石
学习演进时，先分清 “名字” 和 “类型” 的边界
初学 Go 容易把 type MyInt int 和 type MyInt = int 都叫“自定义类型”，但它们在类型系统里地位完全不同。前者是新公民，后者只是身份证上的曾用名。
真正复杂的地方在于：接口场景下，type Res http.ResponseWriter 看似能用，其实是靠方法集匹配撑着；换成结构体就立刻失效。这种差异不是语法问题，而是 Go 类型安全模型的底层逻辑——别名只解决命名，不改变类型身份。
重构中真正难的从来不是写对等号，而是判断哪里该用别名保兼容，哪里该用新类型建隔离。这需要你盯着 reflect.TypeOf() 输出、看接口实现是否断裂、测 JSON marshal 是否一致——而不是只看编译过不过。
