2026年6月19日

第 9 章：泛型、类型集合与迭代器

从类型参数、约束、类型集合、~T、Union、comparable、类型推断、泛型函数与泛型类型，到 slices/maps/cmp/iter、range-over-function、Pull Iterator、Shape、Dictionary、实例化、内联和工程性能验证，系统梳理 Go 泛型与迭代器的面试知识链。

第 9 章：泛型、类型集合与迭代器

版本口径

截至 2026 年 6 月 19 日，当前稳定版为 Go 1.26.4。本章以 Go 1.26 语言规范和 Go 1.26.4 工具链行为为主要口径。泛型在 Go 1.18 引入；Go 1.20 放宽了 comparable 的约束满足规则；Go 1.21 增强类型推断；Go 1.23 正式支持 range-over-function；Go 1.24 正式支持泛型类型别名；Go 1.26 放开了泛型类型在类型参数列表中的自引用限制。(Go)

本章使用以下标记区分结论层级：

[规范]：Go 语言规范保证。
[标准库]：标准库公开 API 契约。
[当前实现]：Go 1.26 系列 gc 编译器或 runtime 的实现细节。
[工程建议]：需要结合 benchmark、profile 和业务约束判断。

阅读定位与关联章节

本章是泛型、类型集合和迭代器的主讲章：类型参数、约束、~T、Union、comparable、类型推断、泛型函数/类型、slices/maps/cmp/iter、range-over-function、Shape、Dictionary、实例化、内联和工程性能验证都在这里集中处理。

关联概念	建议读法
接口、反射、泛型三者如何选	选型总览看第 7 章：接口、反射与泛型：抽象机制导论；本章负责泛型专讲。
defined type、alias、underlying type、方法集	类型系统基础看第 1 章：类型系统、常量、Struct、方法集与嵌入。
constraint interface 与 runtime interface value 的区别	泛型侧在本章；接口运行期表示、ITab 和装箱看第 8 章：Interface 底层实现与设计。
`reflect.TypeFor`、泛型与反射的边界	本章讲泛型 API 设计；反射、unsafe 和布局看第 10 章：Reflection、unsafe 与 Go 内存布局。
`slices`、`maps`、`iter` 在具体容器上的使用	泛型抽象在本章；Slice/Map 具体语义分别看第 4 章：Slice 和第 5 章：Map。

本章速览

先把本章看成一条从“类型参数”到“Iterator 与性能验证”的编译期链路：

读图时抓住三个总结：

泛型的核心是“约束允许哪些类型、因此允许哪些操作”，不是简单替代 interface。
slices/maps/iter 把泛型从语法能力推进到标准库工程模式。
性能结论必须通过 benchmark、profile 和编译器证据验证，不能预设“泛型一定更快”。

一、本章面试目标

1. 知识链

类型参数与实例化
    ↓
Constraint 与 Interface Type Set
    ↓
~T、Union、Intersection、comparable
    ↓
类型推断、统一与反向推断
    ↓
泛型函数、泛型类型、泛型 Receiver
    ↓
泛型别名、自引用约束、F-bounded 风格
    ↓
类型参数可执行的操作
    ↓
泛型零值、nil、类型断言与指针约束
    ↓
slices / maps / cmp / iter
    ↓
range-over-function 与 Pull Iterator
    ↓
Shape、Dictionary、实例化与内联
    ↓
性能验证、API 兼容性与生产排查

2. 初级面试需要掌握

能解释 T any、T comparable、~int。
能编写简单的泛型函数和泛型容器。
知道泛型类型必须实例化。
知道方法不能额外声明自己的类型参数。
知道 var zero T 是获取泛型零值的常用方式。
能使用 slices、maps、cmp。
理解 iter.Seq 和 range-over-function 的基本写法。

3. 中高级面试需要掌握

能从 Type Set 解释约束允许的类型及操作。
能区分 int 和 ~int。
能解释 Union、Intersection 和重叠 Type Set 限制。
能解释 comparable 在 Go 1.20 前后的变化及运行时 panic 风险。
理解参数推断、部分类型实参和 Go 1.21 反向推断。
理解泛型 Receiver、Method Set、指针约束。
能解释为什么不能直接对类型参数做类型断言。
能正确实现支持提前退出的迭代器。
知道 iter.Pull 未完全消费时必须调用 stop。
不把“泛型一定零开销”当作结论。

4. 高级或源码级面试可能继续追问

types2 如何进行类型统一和约束推断。
泛型函数在当前编译器中如何实例化。
Shape-based stenciling 和 dictionary passing 如何配合。
Dictionary 中为什么需要 runtime type、itab、子字典和方法表达式。
为什么不能把当前实现简单概括成“完全单态化”。
range-over-function 如何被编译器改写。
break、return、goto、defer 如何穿过迭代器回调。
iter.Pull 当前如何利用 runtime coroutine。
泛型如何影响内联、逃逸、二进制体积和编译时间。
修改已发布 Constraint 为什么属于 API 兼容性问题。

二、功能介绍与语言语义

2.1 四个核心概念

func Max[T cmp.Ordered](a, b T) T {
	if a < b {
		return b
	}
	return a
}

x := Max[int](10, 20)
y := Max(1.5, 2.5)

概念	在示例中的对应物	含义
Type Parameter	`T`	声明时未知、实例化时被替换的类型占位符
Type Argument	`int`、推断出的 `float64`	实例化时提供给类型参数的实际类型
Constraint	`cmp.Ordered`	限定允许的类型实参，并决定可以对 `T` 做哪些操作
Instantiation	`Max[int]`	用类型实参替换类型参数，得到非泛型函数

[规范] 类型参数本身是一个独立的命名类型占位符。实例化包含两步：

将类型实参替换到泛型声明中。
检查每个类型实参是否满足对应约束。

泛型函数的类型实参可以由编译器推断；泛型类型在使用时则必须明确实例化。类型参数和实例化规则由规范明确规定。(Go)

2.2 泛型函数与泛型类型

泛型函数

func Map[S ~[]E, E, R any](src S, f func(E) R) []R {
	dst := make([]R, len(src))
	for i, v := range src {
		dst[i] = f(v)
	}
	return dst
}

这里：

S 保留调用方的具体 Slice 类型。
E 是元素类型。
R 是结果类型。
~[]E 表示所有底层类型为 []E 的类型。

type UserIDs []int64

ids := UserIDs{1, 2, 3}
texts := Map(ids, func(id int64) string {
	return strconv.FormatInt(id, 10)
})

泛型类型

type Stack[T any] struct {
	items []T
}

func (s *Stack[T]) Push(v T) {
	s.items = append(s.items, v)
}

func (s *Stack[T]) Pop() (T, bool) {
	if len(s.items) == 0 {
		var zero T
		return zero, false
	}

	i := len(s.items) - 1
	v := s.items[i]

	var zero T
	s.items[i] = zero // 解除对引用型元素的潜在持有
	s.items = s.items[:i]
	return v, true
}

使用时必须实例化：

var ints Stack[int]
var names Stack[string]

不能写：

var s Stack // 编译错误：缺少类型实参

2.3 Constraint 本质上是 Interface

[规范] 类型约束是一个 Interface。Interface 定义一个 Type Set，而不是只定义一组方法。类型参数的类型实参必须位于该 Type Set 中。约束同时决定泛型代码中允许对类型参数执行的操作。(Go)

例如：

type Number interface {
	~int | ~int64 | ~float64
}

它的 Type Set 是：

所有底层类型为 int 的类型
        ∪
所有底层类型为 int64 的类型
        ∪
所有底层类型为 float64 的类型

而：

type StringNumber interface {
	~int | ~int64
	fmt.Stringer
}

表示：

(~int ∪ ~int64)
        ∩
实现 fmt.Stringer 的类型

也就是说：

| 形成 Union。
Interface 中不同元素之间形成 Intersection。
方法也是一个 Type Set 条件。

2.4 Basic Interface 与 General Interface

Basic Interface

只通过方法集描述 Type Set 的 Interface 称为 Basic Interface：

type Reader interface {
	Read([]byte) (int, error)
}

Basic Interface 既可以：

作为普通变量类型；
作为 Struct 字段；
作为函数参数；
作为泛型约束。

var r io.Reader

General Interface

包含以下任一内容的 Interface 通常属于 General Interface：

非接口类型项，例如 int；
~T；
Union；
comparable。

type Integer interface {
	~int | ~int32 | ~int64
}

[规范] 非 Basic Interface 只能用作类型约束，或嵌入其他用作约束的 Interface，不能作为普通运行时值类型。(Go)

var x Integer // 编译错误

原因不是它“没有运行时实现”，而是规范明确限制了它的使用位置。

容易混淆的两个 Interface

运行时 Interface Value
    = 静态接口类型 + 动态类型 + 动态值

Constraint Interface
    = 编译期 Type Set + 可用操作集合

Constraint Interface 不等价于“运行时保存多种类型值的容器”。

2.5 `any`

type any = interface{}

any 是空接口的别名，不是新的 Defined Type。

func Identity[T any](v T) T {
	return v
}

any 对类型参数几乎不提供额外操作能力：

可以赋值、传参、返回；
可以获取零值；
不能假设支持 ==；
不能假设支持算术；
不能假设支持 len、索引或 range。

“约束为 any”不是“可以对 T 做任何事”，而是“允许任何类型作为类型实参”。

2.6 `comparable`

comparable 表示可用于 ==、!= 和 Map Key 相关场景的类型约束。

type Set[T comparable] map[T]struct{}

Comparable 与 Strictly Comparable

以下类型通常是严格可比较的：

布尔；
数值；
字符串；
指针；
Channel；
元素严格可比较的数组；
字段严格可比较的 Struct。

Slice、Map、Function 不可比较。

Interface 类型本身可以参与比较，但如果其动态值不可比较，比较会 panic。因此 Interface 是 comparable，但不属于 strictly comparable。

Go 1.20 的变化

Go 1.20 开始，普通 Interface 类型可以满足 comparable 约束：

func Equal[T comparable](a, b T) bool {
	return a == b
}

var a any = 1
var b any = 1

fmt.Println(Equal[any](a, b)) // true

但下面仍会 panic：

var a any = []int{1}
var b any = []int{1}

fmt.Println(Equal[any](a, b))

原因是实际执行的是两个 Interface 动态值的比较，而 Slice 不可比较。

因此：

[规范] T comparable 保证表达式 a == b 可以编译，不保证每一次运行时比较都不 panic——当 T 是 Interface 类型时尤其如此。

这是 Go 1.20 约束满足规则中的特例，规范明确指出这种比较可能在运行时 panic。(Go)

2.7 Type Term、`T` 与 `~T`

type MyInt int

精确类型项 `int`

interface {
	int
}

Type Set 中只有预声明类型 int 本身，不包含 MyInt。

底层类型项 `~int`

interface {
	~int
}

Type Set 包含所有底层类型为 int 的类型，包括：

int
MyInt
type Age int
type Counter int

为什么不能写 `~MyInt`

type Bad interface {
	~MyInt // 编译错误
}

在 ~T 中，T 的底层类型必须就是 T 自身。MyInt 的底层类型是 int，不是 MyInt，所以应写：

type Good interface {
	~int
}

~error 也不合法，因为 error 是 Interface。相关限制由语言规范明确规定。(Go)

2.8 Union 与重叠限制

type Signed interface {
	~int | ~int8 | ~int16 | ~int32 | ~int64
}

Union 中非接口类型项的 Type Set 必须两两不重叠。

type MyInt int

type Bad interface {
	~int | MyInt
}

该约束不合法，因为 ~int 已经包含 MyInt。

为什么限制重叠

如果允许任意重叠：

编译器需要处理一个类型同时属于多个 Term 的情形；
约束规范化和推断会更复杂；
某些操作的来源会变得不清晰。

当前规范要求非接口 Term 两两不相交。

Union 的实现限制

多个 Term 的 Union 不能包含：

comparable；
声明方法的 Interface；
嵌入上述 Interface 的 Interface。

type Bad interface {
	~int | fmt.Stringer // 编译错误
}

不过可以通过 Intersection 表达“底层为某些类型并实现方法”：

type Good interface {
	~int | ~int64
	fmt.Stringer
}

重叠规则、General Interface 使用限制以及多 Term Union 的实现限制均写入规范。(Go)

2.9 泛型方法的限制

泛型类型可以有方法

type Pair[A, B any] struct {
	First  A
	Second B
}

func (p Pair[A, B]) Swap() Pair[B, A] {
	return Pair[B, A]{
		First:  p.Second,
		Second: p.First,
	}
}

Receiver 必须声明与基础泛型类型相同数量的类型参数，但名字可以不同：

func (p Pair[X, Y]) FirstValue() X {
	return p.First
}

方法不能自行声明额外类型参数

以下代码不合法：

type Box[T any] struct {
	Value T
}

// 编译错误：方法不能声明额外类型参数。
func (b Box[T]) Map[R any](f func(T) R) Box[R] {
	return Box[R]{Value: f(b.Value)}
}

应改成包级泛型函数：

func MapBox[T, R any](b Box[T], f func(T) R) Box[R] {
	return Box[R]{Value: f(b.Value)}
}

[规范] Method Declaration 的语法不包含独立 Type Parameter List。泛型 Receiver 只能使用 Receiver 声明引入的类型参数。(Go)

为什么没有泛型方法

工程上，泛型方法会显著增加：

Interface Method Set 的匹配复杂度；
动态调用与实例化时机问题；
跨包编译与链接复杂度；
“哪些类型实参需要生成代码”的判断难度。

但这些属于设计动机。面试时首先应回答：当前语言规范不支持。

2.10 类型推断

2.10.1 参数推断

func First[T any](values []T) T {
	return values[0]
}

x := First([]int{10, 20})

编译器由 []int 和 []T 的关系推断：

T = int

2.10.2 从约束推断关联类型参数

func Clone[S ~[]E, E any](s S) S {
	return append(S(nil), s...)
}

type Names []string

n2 := Clone(Names{"a", "b"})

推断结果：

S = Names
由 Names 的底层类型 []string
继续推出 E = string

2.10.3 部分类型实参

显式类型实参必须是完整类型实参列表的前缀：

func Pair[A, B any](a A, b B) (A, B) {
	return a, b
}

a, b := Pair[int](1, "go")
// A 显式为 int
// B 推断为 string

不能省略左边而显式指定右边：

Pair[, string](1, "go") // 语法错误

也不能写空的类型实参列表：

Pair[](1, "go") // 编译错误

规范明确规定部分实参列表必须是前缀，至少包含第一个类型实参。(Go)

2.10.4 推断失败

func Zero[T any]() T {
	var zero T
	return zero
}

_ = Zero() // 编译错误：无法推断 T

函数没有普通参数可供推断。Go 不会普遍根据调用结果的预期类型反向推断普通调用：

var n int = Zero() // 仍不能据此推断 T

应明确写：

var n int = Zero[int]()

2.10.5 Assignment Context 与 Reverse Inference

Go 1.21 增强了泛型函数值在赋值、返回、传参等上下文中的推断：

var less func(int, int) bool = cmp.Less

等价于：

var less func(int, int) bool = cmp.Less[int]

也可以：

func IntLess() func(int, int) bool {
	return cmp.Less
}

这里推断的对象是 泛型函数值，而不是从普通泛型调用的结果类型任意倒推类型实参。

Go 1.21 还增强了：

泛型函数作为另一个泛型函数参数时的推断；
Interface 方法匹配中的类型推断；
约束方法中的类型推断；
Untyped Constant 的联合推断。(Go)

2.11 类型统一：面试中的理解模型

假设：

func Dedup[S ~[]E, E comparable](s S) S
type IDs []int64

Dedup(IDs{1, 2, 1})

可以把推断抽象成求解方程：

普通参数关系：
IDs ≡ S

约束关系：
S ≡ ~[]E

求解：
S = IDs
underlying(IDs) = []int64
E = int64

实际规范使用更正式的 Unification 规则。面试中不必手写完整算法，但应表达：

根据实参类型和形参类型建立类型方程。
根据约束建立额外方程。
对类型参数进行统一。
处理 Untyped Constant 的默认类型。
检查最终类型实参满足约束。
执行实例化。

2.12 泛型自引用约束与 F-bounded 风格

Go 1.26 放开了“泛型类型不能在自己的类型参数列表中引用自身”的限制：

type Adder[A Adder[A]] interface {
	Add(A) A
}

func AddTwo[A Adder[A]](x, y A) A {
	return x.Add(y)
}

这是一种接近 F-bounded polymorphism 的表达：

A 必须实现“接收 A 并返回 A”的 Add 方法

示例：

type Money int64

func (m Money) Add(other Money) Money {
	return m + other
}

func main() {
	fmt.Println(AddTwo(Money(10), Money(20)))
}

输出：

注意两个边界：

这是 Go 1.26 语言特性；较低语言版本会拒绝。
它不意味着 Interface 可以任意递归嵌入自身。General Interface 的直接或间接循环 Type Element 仍受规范限制。(Go)

2.13 Generic Type Alias

Go 1.24 正式支持带类型参数的类型别名：

type Set[K comparable] = map[K]struct{}
type Vector[T any] = []T

Vector[int] 与 []int 是同一类型：

var v Vector[int]
var s []int

s = v
v = s

Alias 与 Defined Generic Type

type VectorAlias[T any] = []T
type VectorDefined[T any] []T

前者：

与 []T 类型相同；
不创建新 Defined Type。

后者：

创建新的 Defined Generic Type；
可以定义方法；
与 []T 类型不同。

Generic Alias 的限制

type A[T any] = T // 编译错误

Alias RHS 不能直接是该 Alias 自己声明的类型参数。

另外，不能在以下 Alias 上声明方法：

泛型 Alias；
指向已实例化泛型类型的 Alias。

type Box[T any] struct {
	Value T
}

type IntBox = Box[int]

// 编译错误：Alias 指向实例化泛型类型。
func (IntBox) M() {}

Generic Alias 在 Go 1.23 只是实验预览，Go 1.24 才正式进入语言。其类型身份与 Receiver 限制由当前规范明确规定。(Go)

API 迁移价值

package oldpkg

type Set[T comparable] = newpkg.Set[T]

它可以在包重构过程中保持类型身份，减少显式转换和适配层。

但 Alias 不解决所有兼容性问题：

包路径仍改变；
文档和可见 API 仍需迁移；
方法必须属于原 Defined Type；
循环依赖仍不可接受。

2.14 类型参数允许执行哪些操作

核心规则是：

某个操作只有在 Type Set 中所有类型上都有效，才能对该类型参数执行。

算术

type Number interface {
	~int | ~int64 | ~float64
}

func Add[T Number](a, b T) T {
	return a + b
}

+ 对 Type Set 中所有类型都有效。

比较

func Contains[T comparable](values []T, target T) bool {
	for _, v := range values {
		if v == target {
			return true
		}
	}
	return false
}

`len` 和 `cap`

type SliceLike[E any] interface {
	~[]E
}

func Size[S SliceLike[E], E any](s S) int {
	return len(s)
}

cap 也对所有 Slice 类型有效。

索引

type BytesOrString interface {
	~[]byte | ~string
}

func First[S BytesOrString](s S) byte {
	return s[0]
}

Slice 和 String 的索引结果都是 byte，因此读取合法。

但写入不合法：

func SetFirst[S BytesOrString](s S) {
	s[0] = 0 // 编译错误
}

因为 String 不可写。

`range`

对类型参数执行 range 时，Type Set 中类型必须满足规范规定的一致性要求。例如所有类型具有同一种可 range 的底层结构；Channel 类型则要求元素类型一致且都允许接收。(Go)

Slice

func Tail[S ~[]E, E any](s S) S {
	return s[1:]
}

合法，因为所有类型都以 []E 为底层类型。

转换

type Integer interface {
	~int | ~int32 | ~int64
}

func ToInt64[T Integer](v T) int64 {
	return int64(v)
}

转换必须对 Type Set 中每一种类型都合法。

调用方法

type Closer interface {
	Close() error
}

func CloseAll[T Closer](values []T) error {
	for _, v := range values {
		if err := v.Close(); err != nil {
			return err
		}
	}
	return nil
}

只有约束方法集中声明的方法可直接调用。

索引、切片、len、cap、range 等操作都遵循“对 Type Set 中所有类型有效”的规则。规范对混合 String、Slice、Map、Channel 等情形还施加了结果类型一致性要求。(Go)

2.15 泛型零值

最清晰的写法：

func Zero[T any]() T {
	var zero T
	return zero
}

也可以写：

func Zero2[T any]() T {
	return *new(T)
}

但 var zero T 通常更易读，也不容易让读者误以为必然发生堆分配。

不同实例化的零值不同：

T	零值
`int`	`0`
`string`	`""`
`*User`	`nil`
`[]byte`	`nil` Slice
`map[string]int`	`nil` Map
`struct{ X int }`	所有字段为零值的 Struct

[当前实现] *new(T) 是否产生真实堆分配取决于优化和逃逸分析，不应从源码写法直接推断。

2.16 泛型与 `nil`

以下代码不合法：

func IsNil[T any](v T) bool {
	return v == nil
}

因为 T 的 Type Set 包含 int、string、Struct 等不能与 nil 比较的类型。

可以收窄约束：

func IsNilPointer[T any, P ~*T](p P) bool {
	return p == nil
}

也可以分别为 Slice、Map、Channel 等定义约束。

不要用 `any(v) == nil` 模拟通用 nil 判断

func IsNilWrong[T any](v T) bool {
	return any(v) == nil
}

当 v 是 Typed Nil Pointer 时：

var p *int
fmt.Println(IsNilWrong(p)) // false

因为转换后的 Interface：

动态类型 = *int
动态值   = nil

Interface 本身不为 nil。

泛型没有消除 Typed Nil Interface 问题。

2.17 对类型参数做类型断言

不合法：

func IsInt[T any](v T) bool {
	_, ok := v.(int) // 编译错误：v 不是 Interface
	return ok
}

类型断言左操作数必须是 Interface 类型，而类型参数不被当成普通 Interface Value。

可以显式转换为 any：

func IsInt[T any](v T) bool {
	_, ok := any(v).(int)
	return ok
}

但这检查的是动态类型身份：

type Age int

fmt.Println(IsInt(10))      // true
fmt.Println(IsInt(Age(10))) // false

Age 的底层类型是 int，动态类型却是 Age。

类型 Switch 同理：

func Kind[T any](v T) string {
	switch any(v).(type) {
	case int:
		return "int"
	case string:
		return "string"
	default:
		return "other"
	}
}

类型断言要求 Interface 操作数，这是规范而不是编译器偶然限制。(Go)

2.18 Pointer Constraint

假设一个类型的方法只有 Pointer Receiver：

type User struct {
	Name string
}

func (u *User) SetName(name string) {
	u.Name = name
}

可以表达“某个类型是 *T，并且有指定方法”：

type SetNamePointer[T any] interface {
	*T
	SetName(string)
}

func NewNamed[T any, PT SetNamePointer[T]](name string) PT {
	p := PT(new(T))
	p.SetName(name)
	return p
}

调用：

u := NewNamed[User]("Alice")
fmt.Printf("%T %#v\n", u, u)

类型推断可以推断 PT = *User。

这一模式解决了两个问题：

new(T) 产生 *T。
约束要求 *T 的 Method Set 含 SetName。

边界

Pointer Constraint 较难读，不应只为减少一行构造代码而引入。
多个类型参数之间的关系会增加推断和错误信息复杂度。
Method Set 规则没有因泛型而改变。

2.19 泛型容器

Stack

type Stack[T any] []T

func (s *Stack[T]) Push(v T) {
	*s = append(*s, v)
}

零值可用。

Set

type Set[T comparable] map[T]struct{}

func NewSet[T comparable]() Set[T] {
	return make(Set[T])
}

func (s Set[T]) Add(v T) {
	s[v] = struct{}{}
}

这里零值不可直接写入，因为 Nil Map 不能赋值。

并发安全

泛型不提供任何额外并发保证：

type Cache[K comparable, V any] struct {
	m map[K]V
}

多个 Goroutine 并发读写仍然需要：

sync.Mutex；
sync.RWMutex；
单所有者 Goroutine；
不可变快照；
其他同步策略。

“类型安全”与“并发安全”是完全不同的两个维度。

2.20 `slices`、`maps`、`cmp` 与 `iter`

`cmp`

提供：

cmp.Ordered；
cmp.Compare；
cmp.Less；
cmp.Or。

cmp.Ordered 覆盖整数、浮点数和字符串及其相应 Defined Types。

`slices`

常见能力包括：

比较：Equal、Compare；
搜索：Contains、Index；
排序：Sort、SortFunc；
修改：Delete、Insert、Replace；
复制：Clone；
迭代：All、Values、Backward；
收集：Collect、Sorted。

`maps`

常见能力包括：

Clone；
Copy；
Equal；
Keys；
Values；
All；
Collect；
Insert。

组合

keys := slices.Sorted(maps.Keys(m))

for _, k := range keys {
	fmt.Println(k, m[k])
}

maps.Keys 返回 iter.Seq[K]，slices.Sorted 消费该序列并返回排序后的 Slice。标准库鼓励以 iter.Seq、Seq2 作为可组合的迭代接口。(Go Packages)

2.21 Range Over Function

Go 1.23 支持对以下函数签名执行 range：

func(func() bool)
func(func(V) bool)
func(func(K, V) bool)

标准库定义：

type Seq[V any] func(yield func(V) bool)
type Seq2[K, V any] func(yield func(K, V) bool)

一个正确的 Iterator

func Count(n int) iter.Seq[int] {
	return func(yield func(int) bool) {
		for i := 0; i < n; i++ {
			if !yield(i) {
				return
			}
		}
	}
}

消费：

for v := range Count(5) {
	fmt.Println(v)
}

输出：

提前退出

for v := range Count(100) {
	if v == 2 {
		break
	}
	fmt.Println(v)
}

输出：

0
1

执行过程：

调用 Count(100) 返回 Seq
        ↓
编译器调用 Seq(yield)
        ↓
Iterator 调用 yield(0)
        ↓
执行循环体，yield 返回 true
        ↓
Iterator 调用 yield(1)
        ↓
执行循环体，yield 返回 true
        ↓
Iterator 调用 yield(2)
        ↓
循环体 break，yield 返回 false
        ↓
Iterator 必须立即停止

[规范] 循环体终止后，合成的 yield 返回 false，Iterator 不得再次调用它。(Go)

2.22 `yield(false)` 后必须停止

错误实现：

func BadCount(n int) iter.Seq[int] {
	return func(yield func(int) bool) {
		for i := 0; i < n; i++ {
			yield(i) // 忽略返回值
		}
	}
}

调用：

for v := range BadCount(10) {
	if v == 2 {
		break
	}
}

当前实现会检测 Iterator 在 yield 返回 false 后继续调用，并发生 panic。

正确形式：

if !yield(i) {
	return
}

这是 Iterator 作者必须遵守的控制流协议，而不是可选优化。iter 包文档同样规定在 yield 返回 false 后继续调用会 panic。(Go Packages)

2.23 Push Iterator 与 Pull Iterator

Push Iterator

type Seq[V any] func(yield func(V) bool)

生产者主动把值推给 yield：

Iterator → yield(value) → Consumer

优点：

与 for range 自然结合；
通常不需要显式 Channel；
提前退出通过 bool 传播；
易于组合过滤、转换和遍历。

Pull Iterator

消费者主动获取下一个值：

Consumer → next() → Iterator

iter.Pull 将 Push Iterator 转成 Pull Iterator：

next, stop := iter.Pull(Count(10))
defer stop()

for {
	v, ok := next()
	if !ok {
		break
	}
	fmt.Println(v)
}

为什么必须调用 `stop`

next, stop := iter.Pull(seq)
defer stop()

当调用方未消费完整序列时，必须调用 stop，让 Iterator：

结束执行；
执行内部 defer；
关闭文件、连接或其他资源；
释放捕获对象；
终止当前 Pull 状态。

stop 可重复调用；next 在序列结束或停止后继续返回零值和 false。next 与 stop 不能被多个 Goroutine 同时调用。(Go Packages)

2.24 Iterator 中的资源所有权

推荐模式：

func Lines(path string) iter.Seq2[string, error] {
	return func(yield func(string, error) bool) {
		f, err := os.Open(path)
		if err != nil {
			yield("", err)
			return
		}
		defer f.Close()

		scanner := bufio.NewScanner(f)
		for scanner.Scan() {
			if !yield(scanner.Text(), nil) {
				return
			}
		}
		if err := scanner.Err(); err != nil {
			yield("", err)
		}
	}
}

关键点：

资源在 Iterator 被真正调用时打开，而不是创建 Seq 时打开。
defer Close 位于 Iterator 函数内部。
yield 返回 false 后立即 return。
单次 Iterator 是否可重复使用必须写入 API 文档。
Error 是作为序列值返回，还是通过其他方法返回，需要明确协议。

2.25 何时应该使用泛型

适合：

算法仅依赖元素类型，不依赖具体业务语义；
多个类型需要相同的容器或算法；
希望保留输入、输出之间的静态类型关系；
使用 Interface 会丢失结果类型；
需要避免重复代码或代码生成；
API 的调用者可以从类型推断获益。

不适合：

只有一个或两个简单实例；
行为多态比数据形态更重要；
小 Interface 已能清晰表达行为；
约束非常复杂、错误信息难懂；
泛型只是为了“炫技”；
类型组合数量固定且代码生成更容易审计；
需要运行时动态发现字段或方法，反射更符合问题本质。

选择矩阵

技术	最适合解决
泛型	编译期参数化、多类型共享算法、保留类型关系
Interface	行为抽象、运行时动态派发、依赖倒置
Reflection	运行时未知类型、Tag、序列化、框架元编程
Code Generation	需要完全定制代码、性能可预测、协议生成
普通函数	类型数量少、逻辑简单、可读性优先

三、底层实现

3.1 从源码到机器码的处理链

源代码
  │
  ▼
语法解析
  │
  ▼
types2 类型检查
  ├─ 建立 Type Parameter
  ├─ 计算 Constraint / Type Set
  ├─ 类型推断与 Unification
  └─ 检查 Instantiation
  │
  ▼
Unified IR 写入与读取
  ├─ 泛型声明的类型化表示
  ├─ 发现实例化
  ├─ 创建 Shape
  └─ 创建 Dictionary
  │
  ▼
普通 IR
  │
  ├─ 内联
  ├─ 逃逸分析
  ├─ 去虚拟化
  ├─ SSA 优化
  └─ 死代码消除
  │
  ▼
汇编与链接

[规范] 只规定程序语义，不规定必须使用单态化、字典或 Shape。

[当前实现] Go 1.26 的 gc 编译器使用 Unified IR，并结合 Shape-based stenciling 与 Dictionary Passing。不能简单描述成“每个具体类型完整复制一份代码”，也不能描述成“所有泛型都通过运行时字典完全擦除”。(Go)

3.2 类型检查与推断

主要路径：

src/cmd/compile/internal/types2/call.go
    callExpr
       ↓
    arguments
       ↓
    infer
       ↓
    instantiateSignature

`funcInst`

funcInst 处理：

显式类型实参；
部分类型实参；
赋值目标辅助推断；
实例化泛型函数。

当前源码注释明确区分：

推断缺失类型实参后实例化。
类型实参完整时直接实例化。
类型实参不完整且暂不推断时保留部分实例化状态。(Go)

`infer.go`

infer.go 负责：

由普通参数建立类型方程。
由 Constraint 继续推导。
联合处理多个泛型函数参数。
处理 Untyped Constant。
统一类型。
验证最终结果。

src/go/types 中有面向工具链用户的对应实现，而编译器内部使用 src/cmd/compile/internal/types2。两者代码结构高度相似，但使用的 AST、位置和错误报告类型不同。当前 types2/infer.go 还保留了 Go 1.21 反向推断相关处理。(Go)

3.3 实例化不是单纯文本替换

逻辑上可以理解为：

func Add[T ~int | ~int64](a, b T) T {
	return a + b
}

调用：

Add[int](1, 2)

类似得到：

func AddInt(a, b int) int {
	return a + b
}

但当前编译器不一定为每个类型都生成一份完全独立的最终函数体。

实际还需要处理：

泛型函数调用其他泛型函数；
泛型类型的方法；
类型描述符；
Interface 转换；
Method Expression；
反射所需运行时类型；
跨包内联；
多个类型实参可共享 Shape 的情况。

3.4 Shape-based Stenciling

Shape 是编译器用于代码共享的内部类型。

抽象理解：

具体实例：
F[int]
F[MyInt]
F[*User]
F[*Order]

可能映射到若干 Shape 版本，而不是四份完全独立函数体

但不能把 Shape 简化成“只看大小”：

底层类型和操作能力会影响 Shape；
指针类型可有特定共享策略；
Basic Interface Constraint 与 General Constraint 可能影响 Shape；
当前算法未来可以改变。

当前 noder/reader.go 中的 shapify 负责把类型实参映射为 Shape；源码还明确讨论了某些递归类型可能无法最优复用代码。(Go)

3.5 Dictionary Passing

Shape 共享会丢失部分具体类型信息，因此调用时还可能携带隐藏 Dictionary。

当前实现中的 Dictionary 可包含：

┌─────────────────────────────┐
│ 类型参数 Method Expression │
├─────────────────────────────┤
│ 子 Dictionary               │
├─────────────────────────────┤
│ Runtime Type Descriptor     │
├─────────────────────────────┤
│ Interface Table / itab      │
└─────────────────────────────┘

当前源码把 Runtime Dictionary 表示成一个由 uintptr 组成的数组，并按不同区段保存：

类型参数方法表达式；
子字典；
Runtime Type；
itab。

readerDict 同时区分 shaped 与 non-shaped compile-time dictionary。(Go)

调用形态

概念上：

具体 Wrapper
F[int](args...)
    │
    ├─ 准备 Dictionary
    └─ 尾调用 Shaped Function
          F[go.shape.int](dict, args...)

当前 reader.go 中，非 Shape 实例可生成 Wrapper，再向 Shape 版本传入 Dictionary 和普通参数。源码明确构造了 Receiver、Dictionary、普通参数的调用序列。(Go)

3.6 为什么是混合策略

完全单态化

优点：

每个类型都可充分优化；
类型和调用目标通常明确；
运行时字典需求少。

缺点：

二进制膨胀；
编译时间增加；
大量相似机器码。

完全 Dictionary Passing

优点：

代码共享好；
二进制体积相对稳定。

缺点：

更多间接调用；
优化器更难看到具体类型；
可能增加运行时开销。

当前混合策略

Go 当前实现尝试：

用 Shape 共享相似代码；
用 Dictionary 补充具体类型信息；
用 Wrapper 保留实例化入口；
依靠内联、常量传播和去虚拟化消除一部分抽象成本。

所以准确回答是：

当前 gc 编译器采用 Shape-based stenciling 与 Dictionary Passing 的混合实现。它既不是传统 C++ 式完全单态化，也不是 Java 式简单类型擦除。

3.7 内联、逃逸与去虚拟化

内联

泛型函数和普通函数一样，可能被内联：

func Min[T cmp.Ordered](a, b T) T {
	if a < b {
		return a
	}
	return b
}

当调用目标和实例化信息足够明确时，内联后：

Dictionary 访问可能消失；
方法调用可能变成直接调用；
常量传播可继续执行；
边界检查可能被消除。

但不能保证内联：

函数过大；
调用图复杂；
跨包信息不足；
方法通过 Dictionary 间接调用；
编译预算不足。

逃逸

泛型本身不等于堆分配。

func Identity[T any](v T) T {
	return v
}

可能完全在寄存器或栈上执行。

但以下因素可能导致逃逸：

返回指向局部值的指针；
闭包捕获类型参数值；
转换到 Interface 后逃逸；
Iterator 闭包被长期持有；
iter.Pull 的状态需要跨调用存活；
大对象在泛型容器中被引用。

去虚拟化

泛型可以使某些类型关系在编译期更清楚，但带方法约束的调用仍可能经 Dictionary 完成。内联之后，编译器有机会把它恢复为直接调用。

结论只能通过具体构建结果验证。

3.8 泛型是否“零开销”

没有规范保证。

可能优于 Interface 的情况：

避免 Interface 装箱；
不需要动态类型检查；
调用能被内联；
运算直接作用于具体 Shape；
避免反射。

可能不如 Interface 或普通代码的情况：

Dictionary 间接调用无法消除；
生成多个 Shape 或 Wrapper，增加 I-Cache 压力；
泛型函数阻碍某些优化；
编译时间或二进制体积增加；
Iterator Adapter 引入闭包和逃逸。

因此正确表达是：

泛型提供静态类型参数化，常常可以获得接近手写代码的性能，但“零成本”不是语言契约，也不能脱离具体实例化、内联和逃逸结果下结论。

3.9 Range-over-function 的编译器改写

源代码：

for v := range seq {
	use(v)
}

概念上改写为：

seq(func(v T) bool {
	use(v)
	return true
})

但实际远比这个复杂，因为循环体可能包含：

break；
continue；
return；
带标签的 break、continue；
goto；
defer；
嵌套的函数迭代。

当前前端在：

src/cmd/compile/internal/rangefunc/rewrite.go

执行改写。该文件的源码注释明确给出基础改写模型，并使用状态变量处理复杂控制流。break 会转换为 return false，continue 会转换为 return true。(Go)

为什么需要状态机

例如：

func f() int {
	for v := range seq {
		if v == 10 {
			return v
		}
	}
	return -1
}

回调内部不能直接执行外层函数的普通 return。编译器需要：

记录返回状态和值。
让 yield 返回 false。
让 Iterator 返回。
在调用 Iterator 之后完成外层函数返回。

`defer`

如果简单把循环体放进闭包：

seq(func(v T) bool {
	defer cleanup()
	return true
})

defer 会在每次回调返回时执行，而语言语义要求它附着到外层函数。当前编译器和 runtime 使用专门机制把此类 defer 挂到外层函数。相关处理可在 rangefunc/rewrite.go 和 runtime/panic.go 中追踪。(Go)

3.10 `yield` 状态检查

编译器为 Range Function 生成状态变量，以检测：

Iterator 在循环体退出后继续调用 yield；
Iterator 并发或递归地错误调用 yield；
Panic 路径上的非法调用；
Iterator 在 yield 尚未返回时再次进入。

这些检查属于当前实现策略；规范只规定合法调用协议，不保证具体状态字段或 panic 文本。

3.11 `iter.Pull` 的当前实现

iter.Pull 对外表现为：

next, stop := iter.Pull(seq)

当前实现内部使用：

src/iter/iter.go
    newcoro
    coroswitch
        ↓
src/runtime/coro.go

生产者和消费者通过 Coroutine 式控制转移交替运行：

Consumer next()
      │
      ▼
切换到 Iterator
      │
      ├─ 产生一个值
      ▼
切回 Consumer
      │
Consumer 处理值
      │
      └─ 再次 next()

当前 runtime 的 coro 表示“额外并发但不增加并行性”的 Coroutine 控制转移能力。iter 通过 go:linkname 调用 runtime.newcoro 和 runtime.coroswitch。这是实现细节，不是 iter.Pull 的公开 API 契约。(Go)

并发边界

next 和 stop 不允许被多个 Goroutine 同时调用。

这是公开 API 契约，而不是仅仅因为当前 Coroutine 实现“不方便”。

3.12 时间复杂度与空间复杂度

泛型本身没有统一的运行时复杂度。

编译期

类型推断发生在编译期。
Constraint 越复杂，类型检查工作越多。
实例化数量越多，编译和链接工作通常越多。
当前推断实现包含多轮统一与约束处理；类型参数通常很少，因此实际成本多由程序规模和实例化图决定。

运行时

泛型容器或算法的复杂度取决于具体实现：

泛型 Slice 线性扫描：O(n)
泛型二分查找：O(log n)
泛型 Map 查询：平均 O(1)
Iterator 遍历：O(n)
Iterator Adapter 链：通常 O(n × adapter 数量)

空间

可能包括：

具体值存储；
Iterator 闭包；
Pull 状态；
Runtime Dictionary；
多个 Shape 的机器码；
Wrapper 和类型描述符。

3.13 并发安全与 Happens-Before

泛型和 Iterator 不自动建立任何 Happens-Before 关系。

type Box[T any] struct {
	Value T
}

并发读写 Value 仍可能产生 Data Race。

func Values[T any](s []T) iter.Seq[T]

如果一个 Goroutine 遍历 Slice，另一个 Goroutine 修改同一底层数组，仍需要同步。

yield 的普通函数调用顺序在同一 Goroutine 内具有程序顺序，但如果 Iterator 自行启动 Goroutine：

必须管理 Channel 或锁；
必须响应提前退出；
必须传播取消；
必须关闭资源；
必须避免发送方泄漏。

不要因为 API 是 iter.Seq 就假设实现不含并发。

四、源码阅读路径

4.1 推荐阅读顺序

第一步：语言规范

重点章节：

Type parameter declarations
Type constraints
Interface types
Type sets
Instantiations
Type inference
Type unification
Operations on type parameters
Method declarations
For statements with range clause

先掌握规范，再看编译器。否则容易把当前 Shape 设计误认为语言永久语义。(Go)

第二步：类型检查

源码路径	重点
`src/cmd/compile/internal/types2/infer.go`	类型推断、统一、约束推导、Untyped Constant
`src/cmd/compile/internal/types2/call.go`	泛型函数调用、部分实例化、参数检查
`src/cmd/compile/internal/types2/instantiate.go`	类型替换和实例化
`src/cmd/compile/internal/types2/interface.go`	Interface 完成、Type Set
`src/cmd/compile/internal/types2/union.go`	Union 与 Term
`src/cmd/compile/internal/types2/typeparam.go`	Type Parameter
`src/go/types/infer.go`	面向 `go/types` 用户的对应实现
`src/go/types/call.go`	工具链版本的调用检查

推荐调用链：

callExpr
  → funcInst / arguments
  → infer
  → unify
  → instantiateSignature
  → verify

阅读 call.go 时重点看：

显式类型实参如何解析；
部分类型实参如何保留；
Assignment Target 如何参与推断；
泛型函数作为普通参数时如何共同推断；
何时报告 cannot infer。

当前 call.go 中的 funcInst、arguments 和 instantiateSignature 是重要入口。(Go)

第三步：Unified IR 与泛型代码生成

源码路径	重点
`src/cmd/compile/internal/noder/unified.go`	Unified IR 主流程、读取实例化函数体
`src/cmd/compile/internal/noder/reader.go`	Shape、Dictionary、实例化对象读取
`src/cmd/compile/internal/noder/writer.go`	泛型声明及类型信息写入
`src/cmd/compile/internal/noder/irgen.go`	前端 IR 生成入口
`src/cmd/compile/internal/inline`	内联处理
`src/cmd/compile/internal/escape`	逃逸分析
`src/cmd/compile/internal/ssa`	SSA 优化

重点类型和函数：

readerDict
shapify
dictNameOf
dictWord
callShaped
readBodies

关键调用关系：

读取泛型对象
  → 建立具体 Dictionary
  → 建立对应 Shape 对象
  → 读取或扩展函数体
  → Wrapper 向 Shape Function 传递 Dictionary
  → 普通优化管线

当前 unified.go 的 readBodies 会迭代展开待处理的 Dictionary 和函数体。(Go)

旧源码路径警告

较旧文章经常引用：

src/cmd/compile/internal/noder/stencil.go

当前源码目录已经不以该文件作为主要实现入口。Go 1.26 口径应优先阅读：

noder/reader.go
noder/writer.go
noder/unified.go

当前目录清单也能确认这些文件。(Go)

第四步：Range Function

源码路径	重点
`src/cmd/compile/internal/rangefunc/rewrite.go`	Range Function 前端改写
`src/internal/abi/rangefuncconsts.go` 或当前等价路径	Range Function 状态值
`src/runtime/panic.go`	Range Function 中 `defer` 相关 runtime 支持
`src/cmd/compile/internal/ssagen/ssa.go`	后端特殊调用处理

推荐关注：

基础 for range f 到 f(yield) 的转换。
break、continue 如何转成布尔返回。
return、goto 如何借助状态变量穿透闭包。
嵌套 Range Function 如何避免重复改写。
defer 如何附着到外层函数。
非法继续调用 yield 如何被检测。

第五步：Iterator

源码路径	重点
`src/iter/iter.go`	`Seq`、`Seq2`、`Pull`、`Pull2`
`src/runtime/coro.go`	Coroutine 控制转移
`src/slices/iter.go` 或当前等价文件	Slice Iterator
`src/maps/iter.go` 或当前等价文件	Map Iterator
`src/slices/sort.go`	Iterator 收集与排序结合
`src/reflect/iter.go`	反射迭代 API

关键调用链：

iter.Pull(seq)
  → runtime.newcoro
  → Iterator 执行到 yield
  → runtime.coroswitch
  → next 返回
  → 下一次 next 再切换
  → stop 终止 Iterator

4.2 从源码可推导的典型面试答案

问：Go 泛型是单态化吗？

答：

语言规范没有规定。当前 gc 编译器使用 Shape-based stenciling 与 Dictionary Passing 的混合方案。具体实例可能通过 Wrapper 调用共享的 Shape Function，同时传入包含方法、Runtime Type、itab 等信息的 Dictionary。

问：Range Function 是 Runtime 调度机制吗？

答：

for range 对函数的语言语义主要通过编译器前端改写实现，不要求为每次遍历启动 Goroutine。普通 Push Iterator 本质上是函数调用。iter.Pull 为了把 Push 模型转换为 Pull 模型，当前实现才使用 runtime Coroutine。

问：泛型调用一定有 Dictionary 吗？

答：

不能作为语言结论。当前实现中，具体生成方式取决于实例化、Shape、调用方式和优化；即使有 Dictionary，内联后相关开销也可能被消除。

问：泛型一定不装箱吗？

答：

类型参数值本身不等于 Interface Value，但代码若显式转换为 any、调用需要 Interface 的 API，或发生逃逸，仍可能产生 Interface 包装和分配。

五、常用场景与工程取舍

5.1 通用集合算法

func Filter[S ~[]E, E any](src S, keep func(E) bool) S {
	dst := make(S, 0, len(src))
	for _, v := range src {
		if keep(v) {
			dst = append(dst, v)
		}
	}
	return dst
}

适合：

算法与业务类型无关；
需要保留具体 Slice 类型；
调用方希望静态类型安全。

不适合：

只有一个调用点；
回调本身占主要复杂度；
数据量小且抽象增加阅读成本。

替代方案：

普通函数；
为业务类型定义方法；
Iterator Pipeline；
代码生成。

需要 Benchmark：

大 Slice；
回调很小；
分配敏感；
与原地过滤方案比较。

5.2 泛型缓存和仓储层

type Repository[ID comparable, T any] interface {
	Get(context.Context, ID) (T, error)
	Save(context.Context, T) error
}

潜在问题：

约束只能表达类型关系，不能表达事务语义。
不同实体的查询、索引和错误契约往往并不相同。
过度泛化容易产生“万能 Repository”。
返回零值加 Error 时要明确不存在语义。
并发安全和生命周期仍需单独约定。

更合适的边界通常是：

底层容器或基础数据访问工具使用泛型；
业务 Repository 保持领域化 API。

5.3 泛型 Option

type Option[T any] func(*T)

func Apply[T any](value *T, options ...Option[T]) {
	for _, option := range options {
		option(value)
	}
}

优点：

Option 与目标类型静态绑定；
避免错误类型的 Option 混用。

风险：

Option 闭包可能捕获大对象；
Option 执行顺序可能影响结果；
重复应用是否幂等需要定义；
对外暴露 *T 可能破坏不变量。

5.4 Iterator Pipeline

func MapSeq[A, B any](src iter.Seq[A], f func(A) B) iter.Seq[B] {
	return func(yield func(B) bool) {
		for v := range src {
			if !yield(f(v)) {
				return
			}
		}
	}
}

func FilterSeq[T any](src iter.Seq[T], keep func(T) bool) iter.Seq[T] {
	return func(yield func(T) bool) {
		for v := range src {
			if keep(v) && !yield(v) {
				return
			}
		}
	}
}

适合：

惰性处理；
不想中间分配完整 Slice；
数据流可能提前结束；
序列来自树、文件或数据库游标。

不适合：

需要频繁随机访问；
需要多次遍历但 Iterator 是单次的；
Adapter 层级过深；
错误和资源协议难以表达。

性能取舍：

可减少中间 Slice；
但会增加闭包、调用层级和潜在逃逸；
必须通过 Benchmark 与 Profile 判断。

5.5 Interface、泛型和反射的选择

使用 Interface

当核心问题是：

“对象能做什么？”

例如：

type Writer interface {
	Write([]byte) (int, error)
}

使用泛型

当核心问题是：

“输入和输出之间存在什么编译期类型关系？”

例如：

func Map[A, B any]([]A, func(A) B) []B

使用反射

当类型只能在运行时得知：

Struct Tag；
动态字段；
通用序列化；
Dependency Injection Framework。

使用代码生成

当需要：

完全展开的高性能代码；
协议编译；
可审计的序列化；
避免反射；
固定类型集合。

5.6 Constraint 的 API 取舍

过窄

type Integer interface {
	int | int64
}

不接受：

type UserID int64

若希望接受，应写：

type Integer interface {
	~int | ~int64
}

过宽

func Add[T any](a, b T) T

函数体无法使用 +。

方法过多

type Entity interface {
	comparable
	Validate() error
	Clone() Entity
	String() string
}

问题：

Type Set 可能意外变窄；
Pointer/Value Method Set 难以满足；
调用方适配成本增加；
后续添加方法是破坏性变更。

约束应表达算法真正需要的最小能力，而不是对领域对象的完整描述。

六、代码陷阱题

题 1：`int` 与 `~int`

package main

type MyInt int

func Exact[T int](v T) {}
func Underlying[T ~int](v T) {}

func main() {
	var v MyInt
	Exact(v)
	Underlying(v)
}

先判断： 是否编译？

答案： Exact(v) 编译错误；Underlying(v) 合法。

逐行分析：

MyInt 是新的 Defined Type。
int Term 的 Type Set 只有 int。
~int 包含所有底层类型为 int 的类型。
因此 MyInt 不满足 int，但满足 ~int。

依据： T 是精确类型项，~T 是底层类型集合。(Go)

继续追问：

type Alias = int 是否满足 int？满足，因为 Alias 与 int 相同。
~MyInt 为什么不合法？
cmp.Ordered 为什么大量使用 ~？

题 2：Union 重叠

package main

type MyInt int

type Number interface {
	~int | MyInt
}

func main() {}

先判断： 是否编译？

答案： 编译错误。

逐行分析：

~int 已包含 MyInt。
非接口 Union Term 的 Type Set 必须两两不相交。
~int 与 MyInt 的交集不是空集。

依据： Union Term 的 Pairwise Disjoint 规则。(Go)

继续追问：

为什么 float32 | Float 可能合法？
Interface Term 与非 Interface Term 的重叠规则为何不同？
如何重构该 Constraint？

题 3：General Interface 作为变量

package main

type Integer interface {
	~int | ~int64
}

var x Integer

func main() {}

先判断： 是否编译？

答案： 编译错误。

逐行分析：

Integer 含 Type Term，是 General Interface。
General Interface 只能作为约束或约束中的 Interface Element。
它不能作为运行时变量类型。

依据： 非 Basic Interface 使用位置限制。(Go)

继续追问：

var x interface{ M() } 为什么合法？
comparable 能否作为 Struct 字段？
Constraint Interface 与运行时 Interface Value 有何区别？

题 4：Go 1.20 后的 `comparable`

package main

import "fmt"

func Equal[T comparable](a, b T) bool {
	return a == b
}

func main() {
	var a any = []int{1}
	var b any = []int{1}

	fmt.Println(Equal[any](a, b))
}

先判断： 编译错误、输出还是 panic？

答案： Go 1.20 及以后可以编译，运行时 panic。

逐行分析：

any 从 Go 1.20 起可以满足 comparable。
实例化后执行的是 Interface 比较。
两个动态值都是 Slice。
Slice 不可比较，因此 panic。

依据： Go 1.20 的 Constraint Satisfaction 特例，以及 Interface 比较规则。(Go)

继续追问：

“满足 comparable”与“实现 comparable”有什么区别？
如何避免 map[any]V 的同类风险？
泛型库是否应接受 any 作为 Key？

题 5：NaN 与 `comparable`

package main

import (
	"fmt"
	"math"
)

func Equal[T comparable](a, b T) bool {
	return a == b
}

func main() {
	n := math.NaN()
	fmt.Println(Equal(n, n))
}

答案：

false

逐行分析：

float64 是 comparable。
Comparable 只表示允许使用 ==。
IEEE 754 规定 NaN 与任何值比较都不相等，包括自身。
泛型不会改变浮点比较语义。

继续追问：

NaN 作为 Map Key 会怎样？
为什么插入后可能无法用“同一个 NaN 值”查回？
slices.Equal 比较含 NaN 的 Slice 会怎样？

题 6：返回值无法推断 T

package main

func Zero[T any]() T {
	var zero T
	return zero
}

func main() {
	var x int = Zero()
	_ = x
}

先判断： 是否能由左侧 int 推断？

答案： 不能，编译错误。

逐行分析：

普通泛型函数调用主要从实参及约束推断。
Zero 没有普通参数。
Go 1.21 的反向推断主要增强泛型函数值在赋值等上下文中的实例化，不等于从任意调用结果类型倒推。

应写：

var x int = Zero[int]()

继续追问：

var f func() int = Zero 是否能推断？
泛型类型能否像函数一样省略类型实参？
为什么返回值推断容易产生歧义？

题 7：部分类型实参

package main

import "fmt"

func Pair[A, B any](a A, b B) (A, B) {
	return a, b
}

func main() {
	a, b := Pair[int](1, "go")
	fmt.Printf("%T %T\n", a, b)
}

答案：

int string

逐行分析：

A 显式指定为 int。
B 根据第二个实参推断为 string。
部分类型实参必须从左向右形成前缀。

依据： Partial Type Argument List 规则。(Go)

继续追问：

能否只指定 B？
为什么不能写 Pair[](1, "go")？
泛型类型是否支持部分实参？

题 8：Reverse Inference

package main

import "cmp"

var less func(int, int) bool = cmp.Less

func main() {
	println(less(1, 2))
}

先判断： 是否编译？

答案： Go 1.21 及以后编译，输出 true。

逐行分析：

左侧目标类型为 func(int, int) bool。
右侧是泛型函数值 cmp.Less。
编译器由 Assignment Context 推断 T = int。
等价于 cmp.Less[int]。

依据： Go 1.21 类型推断增强。(Go)

继续追问：

作为返回值能否推断？
泛型函数作为另一个函数参数时如何推断？
这与 Zero() 的返回值推断有何不同？

题 9：泛型方法声明额外参数

package main

type Box[T any] struct {
	Value T
}

func (b Box[T]) Map[R any](f func(T) R) Box[R] {
	return Box[R]{Value: f(b.Value)}
}

func main() {}

答案： 编译错误。

逐行分析：

Box[T] 的 Receiver 可以引入 T。
方法本身不能再声明 [R any]。
应改成包级函数：

func MapBox[T, R any](b Box[T], f func(T) R) Box[R]

依据： Method Declaration 语法和泛型 Receiver 规则。(Go)

继续追问：

为什么泛型方法会使 Interface 实现复杂化？
Receiver 类型参数名字必须与类型定义一致吗？
能否在非泛型类型的方法上使用包级泛型函数？

题 10：直接对 T 断言

package main

func IsString[T any](v T) bool {
	_, ok := v.(string)
	return ok
}

func main() {}

答案： 编译错误。

逐行分析：

类型断言左侧必须是 Interface。
类型参数虽然受 Interface Constraint 约束，但其值不是普通 Interface Value。
可写 any(v).(string)。

依据： Type Assertion 规则。(Go)

继续追问：

转成 any 是否可能发生装箱？
switch any(v).(type) 的动态类型是什么？
为什么 ~string 不等于断言到 string？

题 11：Defined Type 的断言

package main

import "fmt"

type Name string

func IsString[T any](v T) bool {
	_, ok := any(v).(string)
	return ok
}

func main() {
	fmt.Println(IsString("go"))
	fmt.Println(IsString(Name("go")))
}

答案：

true
false

逐行分析：

"go" 的动态类型为 string。
Name("go") 的动态类型为 Name。
类型断言检查类型身份，不检查底层类型。

继续追问：

如何用反射检查 Kind？
switch v := any(x).(type) 中 v 的类型是什么？
能否使用 Constraint 在编译期避免该断言？

题 12：泛型 nil 判断

package main

func IsNil[T any](v T) bool {
	return v == nil
}

func main() {}

答案： 编译错误。

逐行分析：

any 的 Type Set 包含不可与 nil 比较的类型。
操作必须对所有类型实参合法。
应为 Pointer、Slice、Map、Channel 等分别收窄约束。

继续追问：

any(v) == nil 为什么不能识别 Typed Nil？
能否定义一个覆盖所有 nil-able 类型的实用 Constraint？
为什么不同 nil-able 类型的通用操作仍然有限？

题 13：泛型零值

package main

import "fmt"

func Zero[T any]() T {
	var zero T
	return zero
}

func main() {
	fmt.Printf("%#v\n", Zero[[]int]())
	fmt.Printf("%#v\n", Zero[map[string]int]())
	fmt.Printf("%#v\n", Zero[string]())
}

答案：

[]int(nil)
map[string]int(nil)
""

具体格式可能受 fmt 表示影响，但语义分别是 Nil Slice、Nil Map、空字符串。

逐行分析：

每个类型参数实例都有对应类型的语言零值。
var zero T 不依赖反射或 Interface。
Nil Slice 可 append，Nil Map 不可写入。

继续追问：

*new(T) 是否一定分配？
如何避免 Pop 后容器继续引用对象？
零值可用性如何影响泛型容器设计？

题 14：Pointer Constraint

package main

import "fmt"

type User struct {
	Name string
}

func (u *User) SetName(name string) {
	u.Name = name
}

type NamedPtr[T any] interface {
	*T
	SetName(string)
}

func NewNamed[T any, PT NamedPtr[T]](name string) PT {
	p := PT(new(T))
	p.SetName(name)
	return p
}

func main() {
	u := NewNamed[User]("Alice")
	fmt.Println(u.Name)
}

答案：

Alice

逐行分析：

PT 的 Type Set 要求类型为 *T。
同时要求 Method Set 含 SetName。
当 T = User 时，PT 被推断为 *User。
new(T) 转换为 PT 后可以调用约束方法。

继续追问：

若 SetName 是 Value Receiver 会怎样？
~*T 与 *T 有什么差别？
何时 Pointer Constraint 会让 API 过于复杂？

题 15：Slice 与 String 混合 Type Set

package main

type BytesOrString interface {
	~[]byte | ~string
}

func First[S BytesOrString](s S) byte {
	return s[0]
}

func SetFirst[S BytesOrString](s S) {
	s[0] = 0
}

func main() {}

答案：

First 合法。
SetFirst 编译错误。

逐行分析：

[]byte 和 string 索引读取结果都是 byte。
String 元素不可赋值。
写索引不是对 Type Set 中所有类型都有效。

依据： 类型参数索引操作的一致性规则。(Go)

继续追问：

对这个约束切片是否总是合法？
为什么 Map 与 Slice 混合约束更受限制？
如何改成只允许可写 Byte Slice？

题 16：Pointer Receiver 与 Method Set

package main

type Counter int

func (c *Counter) Inc() {
	*c++
}

type Incrementer interface {
	Inc()
}

func Apply[T Incrementer](v T) {
	v.Inc()
}

func main() {
	var c Counter
	Apply(c)
}

答案： Apply(c) 编译错误，Apply(&c) 合法。

逐行分析：

Inc 只属于 *Counter 的 Method Set。
Counter 不满足 Incrementer。
泛型 Constraint 使用普通 Method Set 规则，不存在“调用时自动取地址帮助满足约束”。

继续追问：

为什么可寻址变量能写 c.Inc()？
为什么这种语法糖不影响 Interface 实现？
泛型推断是否会自动把 Counter 改成 *Counter？

题 17：Generic Alias 的类型身份

package main

type Vector[T any] = []T

func main() {
	var v Vector[int]
	var s []int

	v = s
	s = v
}

答案： Go 1.24 及以后合法。

逐行分析：

Vector[int] 是 []int 的 Alias。
二者是相同类型。
不需要显式转换。

版本边界：

Go 1.23 仅为实验预览。
go.mod 中的语言版本低于 1.24 时不能依赖该语法。
Go 1.24 正式支持。(Go)

继续追问：

type Vector[T any] []T 有何不同？
Alias 能否定义方法？
Generic Alias 如何用于包迁移？

题 18：Alias Receiver

package main

type Box[T any] struct {
	Value T
}

type IntBox = Box[int]

func (IntBox) Print() {}

func main() {}

答案： 编译错误。

逐行分析：

IntBox 是 Alias。
它指向实例化泛型类型 Box[int]。
规范禁止在这种 Alias 上声明方法。
方法应声明在原 Defined Type Box[T] 上。

依据： Alias Receiver 限制。(Go)

继续追问：

普通非泛型 Alias 能否作为 Receiver？
为什么方法的包归属和 Defined Type 重要？
Alias 是否复制原类型的方法？

题 19：自引用约束版本

package main

type Adder[A Adder[A]] interface {
	Add(A) A
}

func Add[A Adder[A]](a, b A) A {
	return a.Add(b)
}

func main() {}

答案：

Go 1.26 语言版本下合法。
Go 1.25 及以前不合法。

逐行分析：

Adder 在自己的类型参数约束中引用 Adder[A]。
Go 1.26 放开了该限制。
这是 F-bounded 风格约束。

依据： Go 1.26 Release Notes。(Go)

继续追问：

这与 Interface 递归嵌入自身有何不同？
如何实现 ComparableTo[T] 一类约束？
该模式是否应广泛用于业务 API？

题 20：Range Function 提前退出

package main

import (
	"fmt"
	"iter"
)

func Count(n int) iter.Seq[int] {
	return func(yield func(int) bool) {
		for i := 0; i < n; i++ {
			if !yield(i) {
				return
			}
		}
	}
}

func main() {
	for v := range Count(10) {
		fmt.Println(v)
		if v == 2 {
			break
		}
	}
}

答案：

0
1
2

逐行分析：

Iterator 依次调用 yield(0)、yield(1)、yield(2)。
当循环体执行 break 时，yield(2) 返回 false。
Iterator 检查到 false 后返回。

依据： Range Function 语义。(Go)

继续追问：

continue 对应什么返回值？
外层函数 return 如何实现？
Iterator 的 defer 是否会执行？

题 21：忽略 `yield(false)`

package main

import "iter"

func Bad() iter.Seq[int] {
	return func(yield func(int) bool) {
		for i := 0; i < 10; i++ {
			yield(i)
		}
	}
}

func main() {
	for v := range Bad() {
		if v == 0 {
			break
		}
	}
}

答案： 当前实现发生 panic。

逐行分析：

第一次 yield(0) 触发循环体。
循环体 break，yield 返回 false。
Iterator 忽略返回值，再调用 yield(1)。
违反 Range Function 协议。
当前编译器生成的状态检查检测到非法调用。

依据： 规范规定返回 false 后不得再次调用，iter 文档说明继续调用会 panic。(Go)

继续追问：

Panic 文本是否属于稳定 API？
Iterator 能否把 yield 保存到另一个 Goroutine？
并发调用 yield 会怎样？

题 22：`iter.Pull` 忘记 `stop`

package main

import "iter"

func main() {
	next, _ := iter.Pull(func(yield func(int) bool) {
		defer println("cleanup")
		for i := 0; i < 100; i++ {
			if !yield(i) {
				return
			}
		}
	})

	_, _ = next()
	// 不再调用 next，也没有 stop。
}

答案：

程序不一定立即 panic。
Iterator 可能无法及时完成。
cleanup 不保证在预期生命周期内执行。
Iterator 捕获的资源或状态可能被延长持有。

正确写法：

next, stop := iter.Pull(seq)
defer stop()

依据： Pull 文档要求未消费完整序列时调用 stop。(Go Packages)

继续追问：

stop 是否幂等？
next 在 stop 后返回什么？
next 与 stop 能否并发调用？

题 23：Union 中包含方法 Interface

package main

import "fmt"

type Bad interface {
	~int | fmt.Stringer
}

func main() {}

答案： 编译错误。

逐行分析：

这是包含两个 Term 的 Union。
多 Term Union 当前不能含声明方法的 Interface。
可以改成 Intersection：

type Good interface {
	~int
	fmt.Stringer
}

但该 Good 要求类型既以 int 为底层类型，又实现 String()。

依据： Union Implementation Restriction。(Go)

继续追问：

为什么 ~int | ~string 合法？
为什么 comparable | ~int 不合法？
Intersection 如何缩小 Type Set？

题 24：泛型一定比 Interface 快吗

type Adder interface {
	Add(int) int
}

func ViaInterface(a Adder, x int) int {
	return a.Add(x)
}

func ViaGeneric[T interface{ Add(int) int }](a T, x int) int {
	return a.Add(x)
}

先判断： 哪个一定更快？

答案： 无法仅根据源码判断。

分析：

泛型版本可能：

通过 Shape Function 和 Dictionary 调用；
被内联后变成直接调用；
避免 Interface 装箱。

Interface 版本可能：

发生动态派发；
被编译器去虚拟化；
调用方已持有 Interface，不产生额外包装。

必须比较：

go test -bench=. -benchmem -count=10
benchstat old.txt new.txt
go test -run=^$ -bench=. -gcflags='-m=2'
go tool objdump ...

继续追问：

Benchmark 如何防止 DCE？
如何确认是否内联？
如何确认是否存在 Dictionary 间接调用？

七、面试高频问题

1. 什么是类型参数、类型实参和实例化？

30 秒回答： 类型参数是泛型声明中的类型占位符，类型实参是使用时提供的具体类型，实例化是用类型实参替换类型参数并验证约束的过程。

中高级回答： 泛型函数可以通过调用参数和上下文推断类型实参；泛型类型使用时必须显式实例化。实例化还要验证类型实参满足 Constraint。

源码级回答： types2/call.go 负责泛型调用与部分实例化，infer.go 求解缺失类型实参，instantiateSignature 生成实例化签名。

深挖： 实例化完成后，当前编译器还会进入 Unified IR 的 Shape 和 Dictionary 生成。

常见错误： “泛型就是编译器做字符串替换。”

边界： 替换是理解模型，不是完整实现。

2. Constraint 是什么？

30 秒回答： Constraint 是 Interface，定义类型参数允许的 Type Set，并决定可对该参数执行哪些操作。

中高级回答： 它可以由方法、精确类型项、~T、Union 和嵌入 Interface 组合而成。

源码级回答： types2 会完成 Interface、计算 Type Set，并在推断和实例化时做 Constraint Satisfaction。

深挖： Constraint 不一定能作为普通运行时 Interface 类型。

常见错误： “Constraint 就是一组允许的类型名字。”

边界： 方法也是 Type Set 条件，多个 Interface Element 取交集。

3. `any` 和 `interface{}` 有区别吗？

30 秒回答： 没有类型语义差别，any 是 interface{} 的 Alias。

中高级回答： 用作约束时，表示任何类型都可以作为类型实参，但不授予算术、比较、索引等操作能力。

源码级回答： 类型检查器会把二者视为相同类型。

深挖： any(v) 会创建 Interface 语义，可能影响逃逸和动态类型判断。

常见错误： “any 是泛型专用的新顶层类型。”

边界： 它在 Go 1.18 引入，但只是别名。

4. `int` 与 `~int` 有什么区别？

30 秒回答： int 只匹配 int 本身，~int 匹配所有底层类型为 int 的类型。

中高级回答： type MyInt int 不满足 int Term，但满足 ~int。

源码级回答： Type Set 计算会把 ~int 展开为所有 Underlying Type 为 int 的可能类型集合。

深挖： ~MyInt 不合法，因为 MyInt 的底层类型不是自身。

常见错误： “int 也会自动包含所有别名和 Defined Type。”

边界： Alias 与原类型相同，因此 type A = int 满足 int。

5. Union 与 Intersection 如何形成？

30 秒回答： A | B 是 Type Set 并集；Interface 中多个独立元素是交集。

中高级回答：

interface {
	~int | ~int64
	String() string
}

表示底层为 int 或 int64，并且实现 String()。

源码级回答： 类型检查器会规范化 Union Term，并验证非 Interface Term 两两不重叠。

深挖： 多 Term Union 不能包含 comparable 或带方法的 Interface。

常见错误： 把 Interface 的多行元素也理解成 Union。

边界： 一个空交集 Constraint 可以声明，但无法成功实例化。

6. Basic Interface 与 General Interface 有什么区别？

30 秒回答： Basic Interface 的 Type Set 可以仅通过方法描述；General Interface 包含类型项、~T、Union 或 comparable 等。

中高级回答： Basic Interface 可作为普通运行时类型和约束；非 Basic Interface 只能用于约束相关位置。

源码级回答： 类型检查器会记录 Interface 是否为 Method-only，并限制其使用位置。

深挖： Interface 的 Type Set 永远不包含 Interface 类型本身，而是包含实现它的非 Interface 类型。

常见错误： “所有 Constraint 都可以声明变量。”

边界： interface{} 是 Basic Interface。

7. `comparable` 保证比较永不 panic 吗？

30 秒回答： 不保证。当类型实参本身是 Interface 时，动态值不可比较仍会 panic。

中高级回答： Go 1.20 放宽 Constraint Satisfaction，使普通 Interface 类型可满足 comparable。

源码级回答： 这是规范显式规定的 Constraint Satisfaction 特例。

深挖： map[any]V 也有同样风险。

常见错误： “T comparable 后 == 在运行时绝对安全。”

边界： 若所有实际类型实参都严格可比较，则不会出现该动态值问题。

8. 为什么 Union Term 不能重叠？

30 秒回答： 规范要求非 Interface Term 的 Type Set 两两不相交。

中高级回答： ~int | MyInt 不合法，因为 ~int 已包含 MyInt。

源码级回答： 类型检查器会在构建 Union 时检查 Term 交集。

深挖： 该限制简化 Type Set 规范化、操作判定和推断。

常见错误： “重复类型只是冗余，不会报错。”

边界： Interface Term 有不同的重叠处理规则。

9. 方法为什么不能声明自己的类型参数？

30 秒回答： 当前 Go 语法不支持方法独立声明额外类型参数。

中高级回答： 泛型类型的方法只能使用 Receiver 声明引入的类型参数，需要额外参数时应使用包级泛型函数。

源码级回答： Method Declaration 语法中没有独立 Type Parameter List。

深挖： 泛型方法会让 Interface 方法匹配、跨包实例化和链接显著复杂。

常见错误： 直接写 func (x X[T]) M[R any]()。

边界： Receiver 本身可以声明与基础泛型类型对应的参数。

10. 泛型 Receiver 有什么规则？

30 秒回答： Receiver 必须声明与基础泛型类型相同数量的类型参数。

中高级回答： 参数名字可以不同，约束由原类型定义隐式带入。

源码级回答： Receiver 中看似是实例化语法，但其中标识符实际声明 Receiver Type Parameter。

深挖： 泛型 Alias 或指向实例化泛型类型的 Alias 不能作为 Receiver。

常见错误： Receiver 少写一个类型参数。

边界： 可以用 _ 忽略 Receiver 中不需要使用的类型参数。

11. 类型推断从哪里获得信息？

30 秒回答： 从函数实参、形参、约束以及部分上下文关系中获得。

中高级回答： 还可以根据关联约束推断元素类型，例如由 S ~[]E 和实际 Slice 类型推断 E。

源码级回答： infer.go 建立类型方程并执行 Unification，之后处理 Untyped Constant 和约束验证。

深挖： 泛型函数作为参数时，多个函数的类型参数可以共同参与推断。

常见错误： “编译器只看第一个普通参数。”

边界： 推断失败必须显式提供足够的类型实参。

12. 什么是 Reverse Inference？

30 秒回答： 编译器根据赋值目标、返回目标等上下文，为一个泛型函数值推断类型实参。

中高级回答：

var f func(int, int) bool = cmp.Less

可推断 cmp.Less[int]。

源码级回答： call.go 的泛型函数实例化可接收 Target Type 参与推断。

深挖： Go 1.21 扩展了赋值、Interface 方法匹配和泛型函数参数相关推断。

常见错误： 把它理解为所有泛型调用都能从返回值类型推断。

边界： var n int = Zero() 仍不能按这种方式推断。

13. 部分类型实参有什么规则？

30 秒回答： 可以显式提供完整类型实参列表的前缀，剩余部分由编译器推断。

中高级回答： F[A] 可以让后面的 B、C 推断，但不能跳过 A 只提供 B。

源码级回答： funcInst 会记录已提供的 targs，剩余参数交给推断。

深挖： 泛型类型不支持像泛型函数一样省略部分实参。

常见错误： 写 F[, string]。

边界： 空类型实参列表 F[] 不合法。

14. 泛型 Alias 与泛型 Defined Type 有什么区别？

30 秒回答： Alias 不创建新类型；Defined Type 创建新的类型身份。

中高级回答： Alias 可用于 API 迁移，Defined Type 可以拥有方法并建立新的抽象边界。

源码级回答： 类型检查器内部用 Alias 节点保留别名关系，但类型身份仍指向 RHS。

深挖： Alias 指向实例化泛型类型时不能作为 Method Receiver。

常见错误： “泛型 Alias 会复制一份类型。”

边界： Generic Alias 从 Go 1.24 才正式支持。

15. Go 1.26 自引用约束解决什么问题？

30 秒回答： 允许泛型类型在自身类型参数约束中引用自身，可表达 F-bounded 风格关系。

中高级回答： 例如要求 A 实现 Add(A) A。

源码级回答： 类型检查器需要处理声明尚未完全完成时的递归类型引用。

深挖： 这不取消 Interface Type Element 的递归限制。

常见错误： “Go 1.26 允许所有递归 Constraint。”

边界： 需要 Go 1.26 语言版本。

16. 为什么不能直接对类型参数做类型断言？

30 秒回答： 类型断言要求左操作数是 Interface，类型参数值不是普通 Interface Value。

中高级回答： 可以先转换为 any，但会按动态类型身份判断。

源码级回答： 类型检查阶段会在 Type Assertion 规则处拒绝非 Interface 操作数。

深挖： 将类型参数转换为 Interface 可能影响逃逸、装箱和性能。

常见错误： 认为 Constraint 是 Interface，所以值也自动是 Interface。

边界： 约束方法可直接调用，不需要类型断言。

17. 泛型中怎样获得零值？

30 秒回答：

var zero T

中高级回答： *new(T) 也可表达零值，但 var zero T 更直接。

源码级回答： 是否分配由逃逸分析和优化决定，不应由 new 的表面语法推断。

深挖： 容器删除元素时写入零值可帮助解除引用。

常见错误： 尝试写 return nil 作为任意 T 的零值。

边界： 只有约束确保 T 可为 nil 时才能返回 nil。

18. 泛型中如何判断 nil？

30 秒回答： 不能对 T any 直接与 nil 比较，必须收窄约束。

中高级回答： Pointer、Slice、Map、Channel 等应有各自约束和语义。

源码级回答： 比较表达式必须对 Type Set 中所有类型合法。

深挖： any(v) == nil 存在 Typed Nil 问题。

常见错误： 编写通用 IsNil[T any]。

边界： 反射可以统一检查某些 Nil-able Kind，但会引入运行时复杂度和 panic 边界。

19. 什么是 Pointer Constraint？

30 秒回答： 用 Type Term 和方法约束表达类型参数必须是另一个类型参数的指针，并拥有指定方法。

中高级回答：

interface {
	*T
	Set(string)
}

可解决 Pointer Receiver 构造和调用问题。

源码级回答： *T 是包含类型参数的复合 Type Term，Method Set 继续按普通规则检查。

深挖： 通常需要两个关联类型参数。

常见错误： 期待编译器自动从 T 推导 *T 的方法集。

边界： 复杂 Pointer Constraint 可能降低 API 可读性。

20. Range-over-function 的协议是什么？

30 秒回答： Iterator 接受一个 yield 回调并依次调用；yield 返回 false 后 Iterator 必须停止。

中高级回答： 支持零个、一个或两个迭代值，对应三种特定函数签名。

源码级回答： 编译器前端把循环改写为 Iterator 调用和合成闭包，并用状态机保持 break、return、goto、defer 语义。

深挖： 非法继续调用 yield 会被当前实现检测。

常见错误： 忽略 yield 返回值。

边界： 普通 Push Iterator 不要求启动 Goroutine。

21. `iter.Pull` 为什么需要 `stop`？

30 秒回答： 未消费完整序列时，stop 让 Iterator 完成并释放资源。

中高级回答： 推荐在获取 next, stop 后立即 defer stop()。

源码级回答： 当前实现使用 runtime Coroutine 在消费者和 Iterator 之间转移控制。

深挖： next、stop 不支持并发调用；Iterator panic 会传递给调用方。

常见错误： 认为函数返回后 GC 会立即替自己清理 Iterator。

边界： 完整消费到 next 返回 false 后再调用 stop 仍然合法。

22. Go 泛型是如何实现的？

30 秒回答： 当前编译器采用 Shape 与 Dictionary 的混合策略。

中高级回答： 相似实例共享 Shape Function，隐藏 Dictionary 提供具体类型的 Runtime Type、方法、itab 等信息。

源码级回答： Unified IR 的 readerDict、shapify、callShaped、dictNameOf 是主要阅读点。

深挖： Wrapper 可尾调用 Shape Function；内联后部分 Dictionary 开销可能被消除。

常见错误： “Go 泛型完全单态化”或“Go 泛型完全类型擦除”。

边界： 这是当前 gc 实现，不是语言规范。

23. 泛型是否一定比 Interface 快？

30 秒回答： 不一定，必须 Benchmark。

中高级回答： 泛型可能减少装箱并利于内联，也可能引入 Dictionary 间接调用、代码体积和闭包开销。

源码级回答： 应结合 -m=2、SSA、objdump 查看实际生成代码。

深挖： Interface 调用也可能被去虚拟化。

常见错误： 用“静态派发”四个字直接判断性能。

边界： Benchmark 必须覆盖实际类型、调用形态和数据规模。

24. 修改已发布 Constraint 会破坏兼容性吗？

30 秒回答： 可能会，应把导出的 Constraint 当作 API 契约。

中高级回答：

收窄 Type Set 会拒绝原来合法的调用方。
增加方法会要求调用方类型实现新方法。
放宽 Type Set 可能使库实现原本使用的操作不再合法。
改变 T 与 ~T 会影响 Defined Type。

源码级回答： Constraint 变化会改变 Type Set、推断方程和实例化合法性。

深挖： 下游可能嵌入该 Constraint，变化会沿泛型 API 传播。

常见错误： “Constraint 只影响实现，不属于公开 API。”

边界： 某些放宽在保持实现合法时对既有调用者兼容，但仍需测试下游推断和语义。

八、深挖追问链

追问链一：从 Constraint 到 Type Set

1. Constraint 是什么？

是一个用于限制类型实参的 Interface。

2. Interface 为什么能表达类型集合？

Interface 的语义模型是 Type Set；方法、类型项和嵌入 Interface 都定义集合条件。

3. `~int` 表达什么？

所有底层类型为 int 的类型。

4. `~int | ~string` 表达什么？

两个 Type Set 的并集。

5. Interface 中再写 `String() string` 呢？

与实现该方法的类型集合取交集。

6. 为什么 `~int | MyInt` 不合法？

两个非 Interface Term 的集合重叠。

7. 为什么这种 Constraint 不能声明变量？

它是 General Interface，规范只允许在约束相关位置使用。

8. 生产中如何判断 Constraint 设计是否合理？

检查：

是否使用了算法不需要的方法；
是否意外排除 Defined Type；
是否把运行时行为抽象错误地塞进 Type Set；
是否影响 API 演进。

追问链二：类型推断

1. 编译器怎样从 `F([]int{})` 推断 `T`？

匹配实参 []int 与形参 []T，统一出 T = int。

2. `S ~[]E` 有何作用？

在推断 S 后，可由 S 的底层 Slice 类型继续推断 E。

3. 部分类型实参怎样处理？

显式实参绑定前几个类型参数，剩余参数继续参与推断。

4. 为什么不能只显式指定第二个参数？

规范要求部分列表是完整列表的前缀。

5. Go 1.21 的 Reverse Inference 是什么？

目标函数类型可帮助实例化泛型函数值。

6. 为什么 `Zero()` 仍不能从左侧变量类型推断？

普通调用结果不是该反向推断机制的一般输入；没有普通实参建立类型方程。

7. 推断完成后还有什么步骤？

检查类型实参满足约束，并实例化函数签名和函数体引用。

8. 推断失败如何改善 API？

让类型参数出现在普通参数中，或提供显式构造函数，而不是依赖调用方频繁写类型实参。

追问链三：编译器 Shape 与 Dictionary

1. 泛型是否为每个具体类型生成一份代码？

不一定。

2. Shape 是什么？

编译器用于让一组类型实参共享代码的内部类型表示。

3. 共享代码后具体类型信息从哪里来？

由隐藏 Dictionary 补充。

4. Dictionary 中有什么？

当前实现可能包含方法表达式、子字典、Runtime Type 和 itab。

5. 具体实例怎样调用 Shape Function？

可通过一个 Wrapper 准备 Dictionary，并尾调用 Shape 版本。

6. 为什么不全部单态化？

控制代码膨胀和编译成本。

7. 为什么不全部 Dictionary Passing？

保留优化机会，减少所有操作都依赖间接信息的成本。

8. 如何验证某个调用？

使用：

go test -bench=. -benchmem
go build -gcflags='-m=2'
go tool objdump
go tool nm

追问链四：Range Function

1. `iter.Seq[T]` 是什么？

一个接收 func(T) bool 的函数类型。

2. `for v := range seq` 如何执行？

编译器创建 yield 并调用 seq(yield)。

3. `yield` 返回值表示什么？

true 表示继续，false 表示循环体已经终止，Iterator 必须停止。

4. `break` 怎么实现？

循环体闭包返回 false。

5. 外层函数的 `return` 怎么实现？

编译器保存控制流状态和返回值，停止 Iterator 后在外层完成返回。

6. `defer` 为什么麻烦？

简单闭包改写会让 defer 附着到回调，而不是外层函数。

7. Iterator 能保存 `yield` 稍后调用吗？

不应这样设计；yield 只在 Iterator 调用期间有效，越过合法生命周期可能触发状态检查或并发问题。

8. 如何安全管理资源？

在 Iterator 内部获取资源并 defer 释放，任何 yield(false) 路径都立即返回。

追问链五：性能与生产问题

1. 泛型能减少分配吗？

可能，例如避免某些 Interface 装箱；但不是必然。

2. 什么会导致泛型值逃逸？

返回指针、闭包捕获、Interface 转换、长期 Iterator、Pull 状态等。

3. 为什么二进制可能变大？

多个 Shape、Wrapper、Dictionary、类型描述符和实例化方法都会占空间。

4. 为什么 CPU 可能反而上升？

Dictionary 间接调用、未内联 Adapter、多层 Iterator 回调、I-Cache 压力。

5. 如何判断是 Iterator 导致？

分别 Benchmark Slice 循环、Push Iterator、Pull Iterator，并结合 CPU 和 Allocation Profile。

6. 如何发现资源泄漏？

查看 Goroutine Profile、Heap Retention、文件描述符、连接数和业务资源指标，检查提前退出及 stop 路径。

7. Race Detector 能证明 Iterator 安全吗？

只能发现执行路径中发生的 Data Race，不能证明所有路径无 Race，也不能证明资源生命周期正确。

8. 如何防止 Constraint API 变更事故？

为多种 Defined Type、Pointer/Value Receiver、Interface 类型和边界实例建立编译测试与兼容性测试。

九、生产故障与排查

9.1 泛型实例化导致二进制体积增加

现象

二进制明显变大；
构建和链接时间上升；
冷启动或部署传输变慢；
Instruction Cache 命中率下降。

常见原因

大型泛型函数被许多类型实例化。
多个类型无法共享 Shape。
泛型方法链生成多个 Wrapper。
泛型函数未内联但保留大量实例入口。
反射同时要求保留更多 Runtime Type 信息。

排查

go build -o app .
go tool nm -size app
go tool objdump -s 'package\.Function' app

对比改造前后的：

二进制总大小；
相关符号数量；
各实例符号大小；
Dictionary 和 Shape 符号。

处理

缩小泛型函数体；
把与类型无关的大逻辑移到普通函数；
避免为大量业务类型实例化巨型算法；
对固定类型集合考虑普通函数或代码生成；
不要仅为少量重复代码引入多层泛型框架。

9.2 泛型重构后 CPU 升高

可能原因

Interface 调用原本可被去虚拟化，新泛型版本反而经 Dictionary 间接调用；
Iterator Adapter 形成多层回调；
内联预算不足；
Pull Iterator 引入额外控制切换；
新代码产生更多边界检查；
数据布局或缓存局部性改变。

排查步骤

建立同输入的 A/B Benchmark。
使用 -benchmem 看分配变化。
使用 benchstat 判断统计差异。
用 -gcflags='-m=2' 查看内联和逃逸。
用 CPU Profile 找热点。
用 objdump 检查热点调用是否为间接调用。
在生产流量上验证，而不是只依赖微基准。

9.3 Iterator 提前退出导致资源泄漏

典型错误

next, _ := iter.Pull(seq)
v, ok := next()

或 Iterator 忽略：

if !yield(v) {
	return
}

可能后果

文件未关闭；
数据库 Rows 未结束；
网络连接未归还；
Coroutine 或内部状态长时间存活；
捕获的大 Buffer 无法回收；
自定义 Iterator 启动的 Goroutine 泄漏。

排查

检查所有 iter.Pull 是否立即 defer stop()。
检查所有 Iterator 是否处理 yield 返回值。
检查资源获取点和释放点是否在同一个 Iterator 生命周期。
查看 Goroutine Profile。
查看 FD、连接池、数据库连接指标。
对提前 break、return、panic 编写测试。
使用最终化计数器或测试资源验证清理路径。

9.4 Iterator 闭包长期持有大对象

func Values[T any](data []T) iter.Seq[T] {
	return func(yield func(T) bool) {
		for _, v := range data {
			if !yield(v) {
				return
			}
		}
	}
}

返回的 Seq 闭包捕获整个 data。

即使调用方只取一个元素，只要 Seq 仍被保存，整个底层数组就可能保持可达。

排查

Heap Profile 查看 Retained Object。
检查 Iterator 是否被缓存或存入长期 Struct。
检查闭包捕获的 Slice 容量。
使用 go build -gcflags='-m=2' 查看闭包和逃逸。

处理

不长期保存 Iterator；
必要时复制小范围数据；
Iterator 完成后清空持有引用；
避免在全局注册表中保存捕获巨大对象的 Seq。

9.5 `comparable` 引发生产 panic

典型场景

type Cache[K comparable, V any] struct {
	m map[K]V
}

调用方实例化：

Cache[any, Value]

并传入动态 Slice、Map 或 Function 作为 Key。

排查

Panic Stack 是否位于 Map Assignment、Map Access 或 Interface Equality；
检查 K 是否是 Interface；
记录动态类型而非完整敏感值；
为可疑类型增加验证。

处理

不允许 any 作为业务 Key；
使用明确的 String、Integer 或 Struct Key；
API 文档说明 Interface Key 的动态可比较性要求；
必要时在边界通过反射验证 reflect.Type.Comparable，但这会增加运行时成本。

9.6 Constraint 变更导致下游编译失败

场景

旧版：

type ID interface {
	~int64
}

新版：

type ID interface {
	int64
}

下游：

type UserID int64

原本满足，升级后不满足。

排查

检查发布版本中导出 Constraint 的 Diff；
编译多个下游 Fixture；
检查 Defined Type、Alias、Pointer/Value Receiver；
检查 Go 语言版本要求是否提升。

预防

把 Constraint 当作公开 API；
建立 API Compatibility Test；
不随意把 ~T 改成 T；
不随意增加方法；
Release Notes 明确语言版本要求。

9.7 泛型容器出现 Data Race

泛型容器仍然只是普通 Go 数据结构：

type Store[K comparable, V any] struct {
	values map[K]V
}

并发写会：

被 Race Detector 报告；
可能触发 concurrent map writes；
即使换成 Slice 或 Pointer 字段，也可能静默产生错误结果。

排查

go test -race ./...
go test -race -run TestStore ./...

检查：

容器是否声明并发安全；
Callback 是否在锁内执行；
Iterator 是否在锁释放后继续访问内部数据；
返回值是否暴露内部 Map 或 Slice；
Copy-on-write 快照是否真正不可变。

9.8 工具能证明什么

工具	能证明或观察	不能证明
`go test -race`	已执行路径上的 Data Race	所有路径绝对无 Race；资源无泄漏
`go test -bench -benchmem`	特定机器和输入下耗时、分配	生产延迟一定相同
`benchstat`	多轮 Benchmark 差异的统计汇总	Benchmark 设计合理
`-gcflags='-m=2'`	编译器的内联和逃逸决策	实际生产分配频率
`go tool objdump`	当前构建产物的机器码与调用形态	其他平台或其他版本相同
`go tool nm -size`	符号和体积线索	所有体积都由泛型导致
CPU pprof	采样到的 CPU 热点	锁等待、网络等待的完整原因
Heap pprof	当前存活对象或累计分配	所有对象的业务所有权
Goroutine pprof	当前阻塞栈和 Goroutine 数量	每个 Goroutine 都是泄漏
`go tool trace`	调度、阻塞、GC、网络和系统调用时序	长时间生产行为的完整代表
`runtime/metrics`	Heap、GC、Goroutine 等整体指标	直接归因到某个泛型实例
`GODEBUG=gctrace=1`	GC 周期和 Heap 变化	某个 Iterator 必然是根因

十、面试回答模板

10.1 30 秒回答

Go 泛型从 1.18 开始支持，核心是 Type Parameter、Type Argument、Constraint 和 Instantiation。Constraint 本质上是定义 Type Set 的 Interface，~T 表示底层类型为 T 的类型集合，Union 用 |，不同 Interface Element 取交集。当前编译器不是简单完全单态化，而是使用 Shape 和 Dictionary 的混合方案。Go 1.23 还支持对 iter.Seq 一类函数进行 range，Iterator 在 yield 返回 false 后必须停止。

10.2 两分钟回答

泛型主要解决编译期参数化问题，适用于容器和输入输出类型有关联的通用算法。类型参数由 Constraint 限制，Constraint 是 Interface，它的 Type Set 决定可接受的类型和泛型函数体允许的操作。int 只包含精确类型 int，~int 还包含底层类型为 int 的 Defined Type。多个 Term 用 | 取并集，Interface 中多项取交集。

类型实参可以通过普通参数和约束推断，Go 1.21 又增强了泛型函数值在赋值等上下文中的反向推断。方法可以定义在泛型类型上，但方法不能自己再声明额外类型参数。获取泛型零值通常用 var zero T，不能对 T any 直接和 nil 比较，也不能直接做类型断言。

当前 gc 编译器使用 Shape-based stenciling 加 Dictionary Passing。相似实例可以共享 Shape Function，Dictionary 提供具体 Runtime Type、方法和 itab 等信息。性能是否优于 Interface 必须通过 Benchmark、逃逸分析和 objdump 验证。

10.3 五分钟深入回答

从语言语义看，Constraint 是 Interface Type Set。Basic Interface 只通过方法描述，可以作为运行时值；包含类型项、~T、Union 或 comparable 的 General Interface 主要只能作为约束。泛型代码只能执行对 Type Set 中所有类型都合法的操作，所以混合 []byte|string 可以读索引，因为结果都是 byte，但不能写索引，因为 string 不可写。

类型推断会根据实参和形参建立类型方程，再结合约束求解。例如 S ~[]E 在推断 S 为某个 Defined Slice 后，还可以从其底层类型推断 E。显式类型实参可以只提供前缀。Go 1.21 支持根据赋值目标实例化泛型函数值，例如把 cmp.Less 赋给 func(int,int)bool。但没有参数的 Zero[T]() 仍需显式提供 T。

comparable 有版本边界：Go 1.20 后 Interface 类型可以满足 comparable，所以 Equal[any] 能编译，但如果动态值是 Slice，运行时比较仍会 panic。

当前编译器在 types2 阶段完成推断和实例化检查，随后通过 Unified IR 生成 Shape 和 Dictionary。非 Shape Wrapper 可以准备 Dictionary 后尾调用共享 Shape Function。Dictionary 当前包含类型参数方法表达式、子字典、Runtime Type 和 itab。内联后部分开销可能消失，因此不能说泛型总有 Dictionary 开销，也不能说一定生成每个具体类型的一整份代码。

Go 1.23 的 Range Function 会由前端改写成 Iterator 调用和 yield 闭包，并用状态机维持 break、return、goto、defer 语义。yield(false) 后继续调用属于协议错误。iter.Pull 当前使用 runtime Coroutine，把 Push Iterator 转成 next/stop；未完全消费时必须 stop。

10.4 源码级回答

我会先从 types2/call.go 看 funcInst、arguments 和 instantiateSignature，再进入 types2/infer.go 看类型方程、统一和约束推断。工具链侧有 src/go/types 的对应实现。

代码生成阶段看 noder/unified.go 的 readBodies 和 noder/reader.go 的 readerDict、shapify、callShaped、dictNameOf、dictWord。当前实现会区分 shaped 与 non-shaped dictionary，Runtime Dictionary 是若干 uintptr Word，包含方法表达式、子字典、Runtime Type 和 itab。非 Shape 入口可通过 Wrapper 把 Dictionary 传给 Shape Function。

Range Function 看 cmd/compile/internal/rangefunc/rewrite.go，它在前端把 range 改成函数调用，并用状态变量处理复杂控制流。iter.Pull 看 src/iter/iter.go 和 src/runtime/coro.go。

10.5 生产事故分析回答

我会先区分是类型语义错误、性能回退还是生命周期泄漏。若是 panic，优先检查 comparable Interface 的动态值和 Iterator 是否在 yield(false) 后继续调用。若是资源泄漏，检查 iter.Pull 是否 defer stop，以及 Iterator 是否在任何提前退出路径执行清理。

若是 CPU 或分配回退，先用同输入的 Benchmark 和 benchstat 确认差异，再用 -m=2 看内联和逃逸，用 CPU、Heap Profile 找热点，最后用 objdump 确认是否存在无法消除的 Dictionary 间接调用或多层 Iterator 回调。若是二进制膨胀，则用 nm 和符号大小分析 Shape、Wrapper 和实例数量。

修复后还要增加 Defined Type、Interface Key、提前 break、Pull stop、Pointer Receiver 和不同语言版本的回归测试。

十一、本章速记

Constraint 是 Interface，核心语义是 Type Set。
any 是 interface{} 的 Alias，不代表可以对 T 做任意操作。
int 只匹配 int；~int 还匹配底层类型为 int 的 Defined Type。
Union 用 |，Interface 中不同元素取交集。
非 Interface Union Term 的 Type Set 必须两两不重叠。
多 Term Union 不能包含 comparable 或声明方法的 Interface。
General Interface 通常只能用于约束，不能声明普通变量。
comparable 保证比较表达式可编译，不保证 Interface 动态值比较永不 panic。
Go 1.20 放宽了 Interface 类型满足 comparable 的规则。
泛型类型必须实例化；泛型函数可以推断类型实参。
部分类型实参必须是完整列表的前缀。
Go 1.21 支持泛型函数值的 Assignment Context 和 Reverse Inference。
没有普通参数的 Zero[T]() 通常仍需显式提供 T。
方法不能独立声明额外类型参数。
泛型 Receiver 参数数量必须与基础泛型类型一致，名字可以不同。
泛型零值优先写 var zero T。
T any 不能直接与 nil 比较。
类型参数不能直接做普通类型断言；可先转成 any，但检查的是动态类型身份。
Pointer Constraint 可表达 *T 与 Pointer Receiver 方法之间的关系。
类型参数上的操作必须对 Type Set 中所有类型有效。
Go 1.24 正式支持 Generic Type Alias。
Go 1.26 支持泛型类型在类型参数列表中自引用。
Range Function 在 yield 返回 false 后必须立即停止。
iter.Pull 未完全消费时必须调用 stop。
当前 gc 泛型实现是 Shape 加 Dictionary 的混合方案，不是语言保证。
泛型不自动保证零分配、零开销或并发安全。
性能结论必须结合 Benchmark、逃逸分析、Profile 和机器码。
导出的 Constraint 是 API 契约，修改可能破坏下游兼容性。

十二、自测题

12.1 简答题

Type Parameter、Type Argument、Constraint、Instantiation 分别是什么？
为什么 type UserID int64 不满足 interface{ int64 }，却满足 interface{ ~int64 }？
Basic Interface 与 General Interface 的关键区别是什么？
为什么 T comparable 的比较仍可能运行时 panic？
部分类型实参为什么必须是前缀？
Go 1.21 的 Reverse Inference 主要解决什么问题？
为什么泛型方法不能声明额外类型参数？
为什么不能对 T any 直接执行类型断言和 nil 比较？
iter.Seq[T] 与 iter.Pull 的消费模型有何区别？
为什么不能把 Go 泛型实现简单概括成完全单态化？

12.2 代码题

代码题 1

判断是否编译并说明原因：

type Age int

func F[T int](v T) {}
func G[T ~int](v T) {}

func test() {
	var a Age
	F(a)
	G(a)
}

代码题 2

判断运行结果：

func Equal[T comparable](a, b T) bool {
	return a == b
}

func test() {
	var a any = []int{1}
	var b any = []int{1}
	fmt.Println(Equal[any](a, b))
}

代码题 3

修复下面的 API：

type Box[T any] struct {
	Value T
}

func (b Box[T]) Convert[R any](f func(T) R) Box[R] {
	return Box[R]{Value: f(b.Value)}
}

代码题 4

说明哪些函数合法：

type BytesOrString interface {
	~[]byte | ~string
}

func A[S BytesOrString](s S) byte {
	return s[0]
}

func B[S BytesOrString](s S) {
	s[0] = 0
}

代码题 5

找出生命周期问题：

next, _ := iter.Pull(seq)

v, ok := next()
if ok {
	process(v)
}

12.3 系统设计与故障分析题

设计一个泛型并发安全 LRU Cache，要求说明 Key Constraint、零值、锁粒度、返回值所有权、Iterator、监控和关闭语义。
某团队把大量 Interface 工具函数重构成泛型后，二进制增大 35%，CPU 增加 12%。请给出完整排查路径。
设计一个读取大文件的惰性行 Iterator，要求支持提前退出、错误传播、Context 取消和资源释放，说明是否使用 iter.Seq2、Channel 或 iter.Pull。

12.4 参考答案

简答题答案

1

Type Parameter：泛型声明中的类型占位符。
Type Argument：实例化时提供的实际类型。
Constraint：定义允许 Type Set 和可用操作的 Interface。
Instantiation：替换类型参数、验证约束并得到具体函数或类型。

2

Age 是新的 Defined Type，不是 int 本身；但其底层类型是 int。精确 Term 只含该类型，~T 含所有底层类型为 T 的类型。

3

Basic Interface 的 Type Set 可完全由方法描述，可以作为运行时值类型；General Interface 含类型项、~T、Union 或 comparable，通常只能用于约束。

4

Go 1.20 后 Interface 类型可满足 comparable。实例化为 Interface 时，比较仍取决于动态值；动态 Slice、Map、Function 会 panic。

5

规范把部分实参列表定义为完整列表的前缀。这样推断顺序、语法和实例化规则更简单明确。

6

根据赋值目标、返回目标或函数参数目标，为泛型函数值推断缺失类型实参，例如：

var less func(int, int) bool = cmp.Less

7

当前 Method Declaration 语法不允许独立 Type Parameter List。方法只能使用 Receiver 引入的类型参数。

8

类型断言要求 Interface 操作数，而类型参数值不是普通 Interface Value。T any 的 Type Set 又包含不能与 nil 比较的类型，因此 nil 比较也不合法。

9

Seq 是 Push 模型，Iterator 调用 yield；Pull 把它转换成调用方通过 next 主动取值的模型，提前结束时要调用 stop。

10

当前实现既共享 Shape Function，又传递 Dictionary，并可能生成具体 Wrapper；不是每个类型一份完整代码，也不是完全类型擦除。

代码题答案

代码题 1

F(a) // 编译错误
G(a) // 合法

Age 不属于精确类型 int 的 Type Set，但属于 ~int。

代码题 2

Go 1.20 及以后可以编译，运行时 panic。两个 Interface 的动态值都是不可比较的 Slice。

代码题 3

改成包级函数：

func ConvertBox[T, R any](b Box[T], f func(T) R) Box[R] {
	return Box[R]{Value: f(b.Value)}
}

方法不能声明额外类型参数。

代码题 4

A 合法，B 不合法。

String 和 Byte Slice 都能读取索引，结果为 Byte。
String 元素不可写，因此写入操作不是对整个 Type Set 都合法。

代码题 5

忽略了 stop。正确写法：

next, stop := iter.Pull(seq)
defer stop()

v, ok := next()
if ok {
	process(v)
}

未完全消费序列时，stop 使 Iterator 完成并释放资源。

系统设计题参考要点

1. 泛型并发安全 LRU

API 示例：

type Cache[K comparable, V any] struct {
	// internal fields
}

func New[K comparable, V any](capacity int) *Cache[K, V]
func (c *Cache[K, V]) Get(K) (V, bool)
func (c *Cache[K, V]) Put(K, V)
func (c *Cache[K, V]) Delete(K)
func (c *Cache[K, V]) All() iter.Seq2[K, V]
func (c *Cache[K, V]) Close() error

设计要点：

K 使用 comparable，文档中可进一步禁止 Interface Key。
V 的零值通过 var zero V 返回。
Hash Map 加双向链表，平均 Get、Put 为 O(1)。
简单实现使用单 Mutex；高并发可分片，但全局 LRU 顺序会变复杂。
Iterator 不应在持锁状态下长期调用用户 yield。
可先复制 Snapshot 再迭代，代价是 O(n) 分配。
返回 Pointer 或 Slice 型 V 时要说明所有权和可变性。
指标包括命中率、容量、淘汰数、等待时间。
Close 应阻止后台清理 Goroutine 并可重复调用。

2. 泛型重构后体积和 CPU 回退

排查顺序：

固定 Go 版本、GOOS、GOARCH、构建参数。
用 go tool nm -size 比较符号和实例数量。
找出大型泛型函数及其 Type Argument 组合。
objdump 检查是否生成大量 Wrapper 或 Shape。
Benchmark 加 -benchmem 确认微观回退。
-m=2 检查内联失败和新逃逸。
CPU Profile 检查 Dictionary 间接调用和 Adapter 热点。
将与类型无关的大逻辑提取为普通函数。
对热点类型考虑专门实现。
以生产流量回放验证，不只看微基准。

3. 大文件惰性行 Iterator

推荐接口之一：

func Lines(
	ctx context.Context,
	path string,
) iter.Seq2[string, error]

Iterator 内部：

调用时再打开文件。
defer f.Close()。
使用 bufio.Reader 或调整过 Buffer 的 Scanner。
每次读取前后检查 ctx.Done()。
调用 yield(line, nil)。
返回 false 时立即退出。
末尾读取错误通过 yield("", err) 发送一次。
文档说明是单次 Iterator。
不把 yield 传给其他 Goroutine。
若消费者使用 iter.Pull，必须 defer stop()。

是否使用 Channel 取决于是否确实需要独立并发读取。普通文件顺序读取通常直接 Push Iterator 更简单，不需要额外 Goroutine、Channel 和取消协议。

第 9 章：泛型、类型集合与迭代器

阅读定位与关联章节

本章速览

一、本章面试目标

1. 知识链

2. 初级面试需要掌握

3. 中高级面试需要掌握

4. 高级或源码级面试可能继续追问

二、功能介绍与语言语义

2.1 四个核心概念

2.2 泛型函数与泛型类型

泛型函数

泛型类型

2.3 Constraint 本质上是 Interface

2.4 Basic Interface 与 General Interface

Basic Interface

General Interface

容易混淆的两个 Interface

2.5 any

2.6 comparable

Comparable 与 Strictly Comparable

Go 1.20 的变化

2.7 Type Term、T 与 ~T

精确类型项 int

底层类型项 ~int

为什么不能写 ~MyInt

2.8 Union 与重叠限制

为什么限制重叠

Union 的实现限制

2.9 泛型方法的限制

泛型类型可以有方法

方法不能自行声明额外类型参数

为什么没有泛型方法

2.10 类型推断

2.10.1 参数推断

2.10.2 从约束推断关联类型参数

2.10.3 部分类型实参

2.10.4 推断失败

2.10.5 Assignment Context 与 Reverse Inference

2.11 类型统一：面试中的理解模型

2.12 泛型自引用约束与 F-bounded 风格

2.13 Generic Type Alias

Alias 与 Defined Generic Type

Generic Alias 的限制

API 迁移价值

2.14 类型参数允许执行哪些操作

算术

比较

len 和 cap

索引

range

Slice

转换

调用方法

2.15 泛型零值

2.16 泛型与 nil

不要用 any(v) == nil 模拟通用 nil 判断

2.17 对类型参数做类型断言

2.18 Pointer Constraint

边界

2.19 泛型容器

Stack

Set

并发安全

2.20 slices、maps、cmp 与 iter

cmp

slices

maps

组合

2.21 Range Over Function

一个正确的 Iterator

提前退出

2.22 yield(false) 后必须停止

2.23 Push Iterator 与 Pull Iterator

Push Iterator

Pull Iterator

为什么必须调用 stop

2.24 Iterator 中的资源所有权

2.25 何时应该使用泛型

选择矩阵

2.5 `any`

2.6 `comparable`

2.7 Type Term、`T` 与 `~T`

精确类型项 `int`

底层类型项 `~int`

为什么不能写 `~MyInt`

`len` 和 `cap`

`range`

2.16 泛型与 `nil`

不要用 `any(v) == nil` 模拟通用 nil 判断

2.20 `slices`、`maps`、`cmp` 与 `iter`

`cmp`

`slices`

`maps`

2.22 `yield(false)` 后必须停止

为什么必须调用 `stop`

`funcInst`

`infer.go`

`defer`

3.10 `yield` 状态检查

3.11 `iter.Pull` 的当前实现

题 1：`int` 与 `~int`

题 4：Go 1.20 后的 `comparable`

题 5：NaN 与 `comparable`