《Go 语言编程入门》9.3 泛型的取舍

9.3 泛型的取舍

前两节把泛型讲得很香：类型安全、无需断言、能配合标准库。但 Go 团队自己的态度是克制的——官方文档反复强调「generics should be used sparingly（泛型应当谨慎使用）」。这不是保守，而是经验：泛型解决的是一类特定问题，用错了地方，它会让代码比不用更复杂。这一节就来讲清楚那条界线。

本节不再给 TaskAPI 加新功能，而是回看前面写过的代码：Page[T] 该不该是泛型？TaskStore 为什么用接口而不是泛型？我们用真实取舍把第 9 章收束，也为你后续写库时提供一份判断依据。

9.3.1 一个反例：把泛型用过头

假设有人「学会了泛型」之后，把 TaskAPI 的校验函数改成这样：

func Validate[T ~string](title T) error {
	if strings.TrimSpace(string(title)) == "" {
		return ErrInvalidTitle
	}
	return nil
}

它比 func ValidateTitle(title string) error 好在哪？没有。title 只可能是字符串，类型参数 T 是纯粹的噪音：调用方要多看一个 [~string]，函数体内还要写 string(title) 转换，而收益为零。这就是典型的「为泛型而泛型」。

判断标准很简单：当只有一种类型会用到这段代码时，泛型就是负资产。泛型的价值来自「同一逻辑、多种类型」，单一类型直接写具体类型。

9.3.2 三种抽象对比

Go 里表达「同一逻辑作用于不同东西」有三种手段，各有适用面：

记住一句话：接口抽象「能做什么」，泛型抽象「是什么类型」。TaskStore 抽象的是行为（能增、能查），所以是接口；Page[T] 抽象的是元素类型，所以是泛型。搞混这两者，就会写出别扭的代码。

一个常被问到的问题：「接口能不能完全替代泛型？」答案是不能。接口无法表达**「返回值类型与参数类型相同」**这件事——func Sum[T Number](xs []T) T 里，返回值类型依赖参数类型，接口签名写不出来。凡是需要「类型在输入输出间传递」的地方，泛型都有接口不可替代的位置。

9.3.3 该用泛型的三种场景

一、容器类型。 切片、栈、队列、树、Page[T]——它们的逻辑与元素类型无关，元素只是「装进去」。这类是泛型的经典用武之地。

二、通用算法。 排序、查找、映射、过滤。标准库的 slices/maps 就是最好的示范：slices.SortFunc[S ~[]E, E any] 对任何元素类型都能排序，靠的是调用方传入比较函数。

三、避免重复代码的「类型族」。 当你发现自己在为 int、int64、float64 各写一份几乎相同的函数时，一个泛型函数就能收掉。上一节的 Sum 就是例子。

共同特征：逻辑对类型无感知，或只依赖约束保证的少数操作。反过来说，只要函数体里出现了「针对某个具体类型的分支判断」，就该警惕——那往往意味着泛型用错了地方，或者这个逻辑根本不该统一处理。

9.3.4 不该用泛型的三种场景

一、只有一种类型。 如 9.3.1 的反例，直接写具体类型。

二、抽象的是行为而非类型。 如果你关心的是「这个对象能 Save()」，那是接口的活。可以用泛型约束表达方法集：

// Named 是一个带方法的约束：任何有 Name() string 的类型都满足。
type Named interface {
	Name() string
}

// JoinNames 拼接一组具名对象的名称。
func JoinNames[T Named](xs []T, sep string) string {
	names := make([]string, 0, len(xs))
	for _, x := range xs {
		names = append(names, x.Name())
	}
	return strings.Join(names, sep)
}

它能跑，JoinNames([]Tag{{"a"}, {"b"}}, ",") 返回 a,b。但请注意：如果函数体里调用的全是接口方法，那用普通接口参数往往更好——func JoinNames(xs []Named, sep string) string 一样工作，而且调用方不必关心 T。带方法的约束，只有在同时还需要把元素存进 []T、返回 T、或做类型相关的操作时才划算。

三、需要运行时多态。 泛型在编译期就确定了类型，无法在运行时换成另一种实现。要在运行时可插拔，必须用接口。TaskAPI 的 TaskStore 就是典型：它要在测试里换成 fake、将来换成数据库，这种「运行时替换」正是接口的主场。

9.3.5 单态化：泛型为什么快，又不完全快

Java 的泛型靠类型擦除（erasure）——编译后类型参数消失，List<String> 与 List<Integer> 共享一份字节码，代价是装箱与运行时检查。Go 走的是另一条路：单态化（monomorphization），即为每个具体类型生成一份代码。Sum[int] 与 Sum[float64] 会编译成两份独立的机器码，没有装箱、没有类型断言，性能接近手写。

但 Go 的单态化不是完全展开。它采用「GC shape stenciling」：把具有相同「GC 形状」（指针布局一致）的类型归为一组，共享同一份实例化代码，差异部分通过一个隐藏的**字典（dictionary）**参数传递。这意味着：

• 对指针类型（*T、[]T 等），多个类型可能共享代码，代码体积不会爆炸。
• 对值类型（int、float64），会各自实例化。
• 与方法调用结合时，可能有额外的字典查表开销，但通常远小于接口的动态分派。

理解这点的实际意义是：不要用「泛型更快」作为选它的唯一理由。在大多数业务代码里，接口与泛型的性能差异可以忽略；选哪个应该看语义，而不是微基准。

9.3.6 回看 Page[T]：它该是泛型吗

现在可以冷静评估上一节写的 Page[T] 了。它的字段是 Items []T 加上若干 int 元信息：

type Page[T any] struct {
	Items  []T
	Total  int
	Number int
	Size   int
}

它满足该用泛型的第一条场景：这是一个容器，元素类型对它完全透明。如果改成接口版：

type Page struct {
	Items  []any
	Total  int
	Number int
	Size   int
}

调用方每次都要 p.Items[0].(task.Task)，类型信息丢失。所以 Page[T] 用泛型是正确的。

但有一个前提要诚实：只有当 Page 要被多种元素类型复用时，泛型才划算。如果 TaskAPI 只分页 Task 一种，写死 Page[task.Task] 或干脆 TaskPage 也完全可以。泛型的成本是「读者要理解约束」，只有当复用收益大于阅读成本时才值得。

9.3.7 演进路径：别一上来就泛型

一个务实的开发顺序是：具体类型 → 接口 → 泛型，只在被逼着往前一步时才前进。

第一步：先写具体类型。 只有 Task 一种元素时，写 func ListTasks() []Task 就好。简单、直白、易改。

第二步：出现第二种实现时，抽接口。 当 TaskStore 需要内存版与数据库版共存，抽成接口。

第三步：出现「同逻辑、多元素类型」时，才上泛型。 当 Page 要被 Task、User、Log 复用时，泛型才真正回本。

反过来做（一上来就设计一堆泛型接口）会陷入「抽象过早」的陷阱：你猜不准未来的类型参数，最后约束要么过宽（失去类型安全）、要么过窄（用不了）。抽象的时机应当由重复驱动，而不是由想象驱动。

9.3.8 泛型类型别名

Go 1.24 起正式支持泛型类型别名——别名自身也可以带类型参数，例如 type Set[T comparable] = map[T]struct{}；而给已经实例化的泛型类型起短名字则更早就可用：

type Page[T any] struct {
	Items []T
	Total int
}

// TaskPage 是 Page[string] 的别名
type TaskPage = Page[string]

注意 = 号：type A = B 是别名（A 与 B 是同一个类型），type A B 是定义（A 是新类型）。别名在跨包复用泛型实例时很好用——你可以在自己包里定义 type TaskPage = pagination.Page[task.Task]，调用方少写一层类型参数。别名不产生新类型，也不带来额外的方法集，是纯粹的书写便利。

9.3.9 一个具体对比：接口版 Page 的代价

「泛型版不如接口版」的说法在 Page 上站不住脚。把两版并排看，代价立刻显形：

// 泛型版：类型信息完整保留
type GPage[T any] struct{ Items []T }

// 接口版：元素被擦成 any
type IPage struct{ Items []any }

func main() {
	gp := GPage[task.Task]{Items: []task.Task{task.New(1, "写第 9 章")}}
	title := gp.Items[0].Title // 直接取字段，编译期检查

	ip := IPage{Items: []any{task.New(1, "写第 9 章")}}
	title2 := ip.Items[0].(task.Task).Title // 必须断言，类型错了运行时 panic
	_, _ = title, title2
}

接口版有三处代价：取字段要断言、断言失败会 panic、Total/Size 这类元信息虽然能用，但一旦想对 Items 排序就要把 any 逐个转回来。泛型版则把类型错误全部提前到编译期。

反过来说，如果 Page 需要在运行时容纳不同类型（比如一个 Page 里既有 Task 又有 Log），那泛型就无能为力了，只能回到 []any。编译期确定 vs 运行时灵活，是泛型与接口最本质的分界。

9.3.10 泛型 vs 反射

除了接口，还有第三条「泛型之外」的路：反射（reflect）。当你既想要类型灵活、又想要运行时操作时，反射是最后的工具。三者的分工：

反射的代价是编译期完全不检查，字段名写错要到运行时才发现，且性能差、代码难读。所以顺序永远是：能泛型就泛型，需要运行时替换就用接口，两者都做不到才用反射。encoding/json 之所以用反射，正是因为它必须处理编译期未知的结构体——那是反射不可替代的领域。

9.3.11 决策清单

把本节浓缩成一张可以贴在墙上的表：

这张表里唯一需要动脑的是第 2 行与第 3 行的区分：「逻辑相同、元素被当黑盒」与「多种实现、运行时替换」听起来都像「复用」，但前者复用代码，后者复用接口契约。问自己一个问题就能分清：我要复用的是一个「算法」还是一个「插槽」？ 算法用泛型，插槽用接口。

三条可以立刻执行的判断：

• 想不出第二个类型参数 → 用具体类型。
• 需要在测试里替换、或运行时选择实现 → 用接口。
• 元素只被存取、不被「理解」→ 才考虑泛型。

9.3.12 小结

第 9 章到这里结束。三节连起来是一条从「会不会」到「该不该」的路：

最值得带走的一条：泛型是工具，不是目标。Go 的哲学是「先写简单的代码，简单到不够用了再抽象」。泛型让「容器与算法」变简单，却让「只有一种类型的业务逻辑」变复杂。分清这两者，你就已经超过大多数「学会语法就到处套」的使用者了。

给团队落地时的三条约定，可以直接写进代码评审清单：

1. 新增泛型必须能说出「第二个使用它的类型」。说不出，就是过早抽象，退回具体类型。
2. 能靠标准库解决就别自造。slices/maps/cmp 已经覆盖了绝大多数集合操作。
3. 接口与泛型不可互换。要在运行时可替换（测试、插件、多存储）用接口；只是元素类型不同用泛型。

这三条的共同点是：把「为什么用」当成选型的第一问，而不是「能不能用」。语法决定你能做什么，取舍决定你该做什么——后者才是工程能力。

第 10 章我们将进入并发：让 TaskAPI 的后台 worker 批量处理到期任务，用 goroutine 与 channel 搭一条任务队列。

阅读导航：上一节：9.2 slices/maps/cmp 标准库 · 下一节：10.1 goroutine 与调度直觉 。