[!info] related notes

• 所属 MOC：类型与抽象 · 语言基础 · 学习路线
• 前置概念：基本类型、struct 与方法
• 后续概念：方法集、转换与可赋值性、泛型
• 相关：iota 与枚举

Go 类型别名与类型定义

这个概念为什么会出现

类型系统要同时服务两件事：

1. 抽象与安全：UserID 不能当成 OrderID 偷偷传入
2. 演进与兼容：重构时给旧名留别名，避免一次性改爆全仓库

Go 用两种声明回应：

type UserID int64  // 类型定义（defined type）
type LegacyID = int64 // 类型别名（alias）—— Go 1.9+

混用二者是许多 API 设计与迁移错误的根源。

[!abstract] 一句话理解 type A B 创造与 B 不同的新命名类型（可转换、默认可赋值性更严）；type A = B 只是同一类型的另一个名字，完全可互换。

最小可运行示例

先把示例放进业务场景，再看代码：

场景：订单系统里的 UserID / OrderID 防混用

下单链路同时出现“用户 ID”和“订单 ID”，底层都是 int64。
若都写成裸 int64，编译器拦不住 pay(orderID) 误传成用户 ID。
用类型定义拆成 UserID / OrderID；迁移期再给 UserID 留个别名 UID。

package main

import "fmt"

// UserID / OrderID 是两个不同的定义类型（defined type）。
// 业务意图：即使底层都是 int64，也不能在 API 边界默默互换。
// 教学点：type A B 创造新类型身份，不是换名字。
type UserID int64
type OrderID int64

// UID 是 UserID 的别名（alias）。
// 业务意图：重构迁移期兼容旧代码里的短名。
// 教学点：type A = B 与 B 完全同一类型，可直接赋值。
type UID = UserID

// attachOrder 模拟“把用户挂到订单上”的领域函数。
// 签名强制区分两种 ID，避免参数顺序写反却仍能编译。
func attachOrder(user UserID, order OrderID) {
	fmt.Println("attach user", user, "to order", order)
}

func main() {
	var user UserID = 1
	var order OrderID = 2

	// order = user // 编译错误：UserID 与 OrderID 不同名类型
	// 若业务上确实要把“用户数字”写进订单号字段，必须显式转换（罕见且应审视）。
	order = OrderID(user)

	// 别名：UID 与 UserID 可互换，无需转换。
	var legacy UID = user
	attachOrder(legacy, order)
	fmt.Println("order after cast:", order, "legacy uid:", legacy)
}

建议运行：

go run .

期望输出：

attach user 1 to order 1
order after cast: 1 legacy uid: 1

结合场景再看三个关注点

1. 定义类型防混用
   UserID 与 OrderID 不能直接赋值，把“传错 ID”前移到编译期。

2. 需要互通时显式转换
   OrderID(user) 在代码审查里非常显眼，适合当危险信号。

3. 别名用于迁移，不是领域建模
   UID = UserID 给旧名留桥；新领域概念应优先 type X Y，而不是别名。

核心概念与准确模型

类型定义（defined type）

Spec — Type definitions

• 引入新类型，有自己的身份
• 与底层类型可显式转换（规则满足时）
• 不继承底层命名类型已定义的方法；只“共享”底层结构含义
• 同包定义且不是指针或接口的类型，可作为方法的接收者基类型

type Celsius float64
func (c Celsius) String() string { return fmt.Sprintf("%.1f°C", c) }

float64 没有这个方法；Celsius 有。

类型别名（alias）

Spec — Alias declarations · Go 1.9 Release Notes

type MyInt = int

• 编译器视角：MyInt 与 int 完全相同
• 可互赋值、同一 method set
• 主要用于大规模重构迁移与缩短名字

// 迁移期：
// package newpkg
// type Handle = oldpkg.Handle

可赋值性 vs 转换

关系	定义类型 A/B 底层同为 int	别名
直接赋值	通常否（不同命名类型）	是
A(x) 转换	常可以	无意义（已是同型）
底层类型相同	是	同一类型

更细规则见 go-type-conversion-and-assignability 与 Spec — Assignability。

方法集

type MyBytes []byte
// func (b MyBytes) Len() int { return len(b) }  // 可为定义类型加方法

type AliasBytes = []byte
// 不能给 []byte 的别名“单独”加一套与内置切片分叉的方法集——它就是 []byte

给预声明类型加方法必须通过定义类型包装。

结构体与接口

type Point struct{ X, Y int }
type P = Point // 别名

接口满足性：定义类型的方法集按自己的方法计算；别名与原类型一致。

泛型中的角色

Go 1.24+ 支持泛型类型别名，例如 type Set[K comparable] = map[K]bool；实例化后仍是右侧同一类型，不创造新身份。普通别名从 Go 1.9 起可用，不应把泛型别名也标成 1.9。见 Spec 与 go-generics。

边界情况

1. 导出别名：type Public = other.Public 影响 API 表面，godoc 显示别名关系。
2. 循环别名：禁止无意义循环。
3. JSON/反射：reflect.Type 对定义类型显示新名；别名通常显示为原类型。
4. 底层类型链：type A B；type B C——转换规则看底层与未命名类型关系。
5. 用定义类型过度包装：每层都要转换，API 摩擦上升。

常见误区

[!warning] 常见误区：type A B 与 type A = B 同一回事 错误：随机写 =。
正确：要隔离就定义；要改名迁移就别名。

[!warning] 常见误区：以为定义类型继承方法 错误：type MyInt int 自动有“int 的方法”（int 本身也无方法，但套在有方法的命名类型上时更易误解）。
正确：方法集挂在类型身份上；定义类型要自己声明方法。

[!warning] 常见误区：用别名做“单位安全” 错误：type cm = int 期望防止与 inch 混用。
正确：必须用定义类型 type CM int。

[!warning] 常见误区：迁移结束就直接删除公开别名 公开别名可能已是外部调用者依赖的兼容契约。仅在确认使用方迁移完成、满足版本兼容策略后删除；长期保留兼容别名也可以是合理选择。

工程实践

1. ID 类型：type UserID string 防止参数顺序写反。
2. 枚举：定义类型 + iota（go-iota-and-enums）。
3. 重构：先引入别名，逐包替换，再删旧路径（官方推荐别名的动机之一）。
4. 外部依赖类型过长：可本地别名，但勿掩盖所有权。
5. 转换写在边界：领域层用 UserID，存库边界显式转换。
6. 测试：编译期断言不兼容更有价值：var _ UserID = OrderID(1) 应失败。

可验证实验

实验 1：赋值

UserID/OrderID 互赋，看编译器错误。

实验 2：别名

type U = UserID 与 UserID 互赋成功。

实验 3：方法

给定义类型加 String；别名到基础类型无法单独分裂方法集。

实验 4：转换

float64(celsius) 与回转，打印。

实验 5：反射

打印 reflect.TypeOf 名称差异。

本节总结

• 本质：定义 = 新类型身份；别名 = 同一类型的新名字。
• 关键规则：可赋值性、方法集、转换、迁移用途。
• 最易错：用别名求类型安全；误以为继承方法。
• 下一步：go-method-sets-and-receivers；go-type-conversion-and-assignability。

自测题

概念题

1. 如何让 UserID 与 int64 不能直接赋值？
2. 别名主要解决什么工程问题？
3. 定义类型会自动拥有底层命名类型的方法吗？

代码推理题

type A int
type B = A
func (A) M() {}
var b B

b.M() 合法吗？

工程思考题

把第三方 pkg.Client 在本仓库改名迁移到 internal/client，如何用别名分阶段？

参考答案

展开

1. type UserID int64（定义，不是别名）。
2. 渐进重构/兼容改名而不改语义。
3. 不会自动继承；方法集跟类型身份走。
   代码题：合法——B 是 A 的别名，同一类型，方法可调用。
   工程题：先在新路径使用 type Client = old.Client，保持同一类型与方法集，再迁移导入路径。若只是本地包装第三方类型，可以长期保留此别名；改成 type Client old.Client 会创建不同类型且不继承原方法，属于额外 API 变更，不能当作机械收尾。旧兼容入口只有确认使用方迁移后才删除。

延伸阅读与资料来源

资料	类型	支撑
Spec — Type definitions	规范	定义类型
Spec — Alias declarations	规范	别名
Go 1.9 Release Notes	发行说明	别名引入
Spec — Assignability	规范	赋值规则
Effective Go	文档	类型与接口风格