第 4 章类型系统 on Go 语言原本

4.1 运行时类型系统

Mon, 01 Jan 0001 00:00:00 +0000

4.1 运行时类型系统

Go 是静态类型语言，类型检查发生在编译期。但 Go 又保留了相当一部分运行时类型信息（runtime type information, RTTI），正是它支撑起了接口（4.2）、类型断言、类型 switch、反射，以及垃圾回收对指针的精确识别。这一节回答一个看似简单的问题：编译期那套类型，到了运行时还剩下什么、以什么形式留存、又撑起了哪些能力。读懂这一节里那个叫类型描述符的小结构，后面的接口（4.2）、反射与精确 GC（13）就都有了共同的落脚点。

下文给出的结构体都是裁剪后的速写：只保留与设计相关的字段，并在注释里说明它为何存在。完整定义可对照 go1.26 的 internal/abi/type.go 与 reflect 包。

4.1.1 每个类型都有一个描述符

编译器为程序里用到的每一个类型生成一份类型描述符，在 go1.26 的源码里它叫 abi.Type，运行时内部沿用旧名 _type。描述符被编进只读数据段，整个程序运行期间常驻不变。同一个类型在一个程序里通常只有一份描述符，这一点后面判断「类型是否相同」时会用到。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// abi.Type：一个类型在运行时的表示（裁剪后的速写）
type Type struct {
 Size_ uintptr // 该类型一个值占多少字节，分配与拷贝都要它
 PtrBytes uintptr // 值的前若干字节里可能含指针，GC 只需扫到这里
 Hash uint32 // 类型的哈希，类型 switch、接口表查找时避免重算
 TFlag TFlag // 标志位：是否具名、是否带 UncommonType、GC 位图是否按需生成
 Align_ uint8 // 该类型变量的对齐
 FieldAlign_ uint8 // 作为结构体字段时的对齐
 Kind_ Kind // 种类：int、struct、slice、chan… 决定如何解释这块内存
 // 比较该类型两个值是否相等：(指向 A, 指向 B) -> ==?
 // 编译器按类型结构合成，map、接口比较、== 运算都落到它身上
 Equal func(unsafe.Pointer, unsafe.Pointer) bool
 // GC 指针位图：标出该类型哪些字（word）是指针，精确 GC 据此扫描
 GCData *byte
 Str NameOff // 类型名在名字表里的偏移（按需解出可读名字）
 PtrToThis TypeOff // 指向「*T」描述符的偏移，构造指针类型时复用
}

每个字段都为某种运行时能力而存在，挑几样要紧的说。Size_ 是分配器（12）和值拷贝的依据。Kind_ 是一个枚举，告诉运行时「这块内存按哪种类型解释」，它的取值是有限的二十余种基础种类：

4.2 接口

Mon, 01 Jan 0001 00:00:00 +0000

4.2 接口

接口是 Go 类型系统的灵魂。它让「行为」与「实现」解耦，又用一种与众不同的方式做这件事：结构化、隐式的满足，区别于绝大多数主流语言。这一节看接口在运行时怎么表示、方法怎么动态分发、类型断言怎么落地，以及这套设计放进多态的谱系里处在哪个位置。沿用前几节的做法，下文给出的结构体都是裁剪后的速写：只留与设计相关的字段，注释说明它为何存在。完整定义可对照 runtime/runtime2.go、internal/abi/iface.go 与 runtime/iface.go。

4.2.1 两种表示：iface 与 eface

接口值在运行时一律是两个字宽，但分两种。带方法的接口（非空接口）用 iface：一个指向 itab 的指针，加一个指向具体数据的指针。空接口 interface{}（即 any）用 eface：一个指向类型信息 _type 的指针，加一个数据指针。空接口没有方法，不需要方法表，于是直接存类型即可，省下一层间接：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 非空接口：带方法，故需方法表 itab（速写）
type iface struct {
 tab *itab // 接口类型 × 具体类型 的方法表（含动态类型与 Fun 表）
 data unsafe.Pointer // 指向具体值（大于一字或需取址时为堆/栈上副本的指针）
}

// 空接口 any：无方法，直接挂类型信息（速写）
type eface struct {
 _type *_type // 具体值的动态类型
 data unsafe.Pointer
}

data 存的是指针而非值本身。把一个 int 放进接口，运行时会把它装箱（boxing）到一处可寻址的内存，再让 data 指过去，这也是「接口会引入一次分配」这一性能直觉的来源。两字表示是理解后续一切的地基：动态分发、类型断言、乃至下面的 nil 陷阱，都是它的直接推论。

4.3 类型别名

Mon, 01 Jan 0001 00:00:00 +0000

4.3 类型别名

type A = B（类型别名）与 type A B（定义新类型）只差一个等号，语义却根本不同。前者只是给一个已存在的类型取个新名字，后者会造出一个全新的、有独立标识的类型。这个区别看似细微，却牵动着类型相等、方法集、可赋值性（4.1）这一整套规则，也牵动着一个 Go 一贯关心的工程问题：当一份代码不再由原作者维护、却仍要在不破坏兼容的前提下演化时，类型该如何在包之间迁移。这一节先把别名与定义类型的语义讲清，再交代别名为何在 Go 1.9 被引入，最后看它在 Go 1.24 迎来的泛型能力。

4.3.1 别名 vs 定义类型

按语言规范，类型声明分两种形式：别名声明（alias declaration）与类型定义（type definition）。二者的分界就是那个等号。

type Celsius float64 是类型定义，它「创建出一个新的、不同的类型，与给定类型有相同的底层类型与操作」。Celsius 与 float64 从此是两个不同的名义类型（4.1）：各有自己的标识，可以挂自己的方法，彼此之间不能直接赋值，只能显式转换。

type byte = uint8 是别名声明，它只是「把一个标识符绑定到给定类型」。在该标识符的作用域内， byte 就「充当 uint8 的别名」，二者是同一个类型的两个名字，完全可以互换。标准库里 byte（= uint8）、rune（= int32），以及 Go 1.18 起 any（= interface{}），正是这样定义的预声明别名。

别名与定义类型最容易混淆、也最能体现差别的地方，是方法集。看一段会编译失败的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


import "bytes"

type AliasBuf = bytes.Buffer // 别名：就是 bytes.Buffer 本身
type DefBuf bytes.Buffer // 定义类型：底层相同，但方法集为空

func demo() {
	var a AliasBuf
	a.WriteString("x") // OK：AliasBuf 与 bytes.Buffer 是同一类型，方法集完全相同

	var d DefBuf
	d.WriteString("x") // 编译错误：DefBuf 未继承 bytes.Buffer 的任何方法
	_ = bytes.Buffer(d) // 但可显式转换回去：二者底层类型相同
}

DefBuf 与 bytes.Buffer 底层类型相同，因此可以互相显式转换，但 DefBuf 是一个新类型，它不继承 bytes.Buffer 的方法集，d.WriteString 找不到接收者。AliasBuf 则压根不是新类型，它就是 bytes.Buffer，方法集自然一模一样。一句话：定义类型造出新东西（新标识、空方法集、需自行定义方法），别名只给旧东西取个新名（同一标识、同一方法集）。

4.4 进一步阅读的参考文献

Mon, 01 Jan 0001 00:00:00 +0000

3.10 进一步阅读的参考文献

[Ghemawat and Menage, 2009]

Sanjay Ghemawat, Paul Menage. "TCMalloc : Thread-Caching Malloc." Google Inc., 2009 http://goog-perftools.sourceforge.net/doc/tcmalloc.html

第 4 章 类型系统 on Go 语言原本

4.1 运行时类型系统

4.1 运行时类型系统

4.1.1 每个类型都有一个描述符

4.2 接口

4.2 接口

4.2.1 两种表示：iface 与 eface

4.3 类型别名

4.3 类型别名

4.3.1 别名 vs 定义类型

4.4 进一步阅读的参考文献

3.10 进一步阅读的参考文献

第 4 章类型系统 on Go 语言原本