原文：A gentle introduction to generics in Go by Dominik Braun
万俊峰Kevin：我看了觉得文章非常简单易懂，就征求了作者同意，翻译出来给大家分享一下。
本文是对泛型的基本思想及其在 Go 中的实现的一个比较容易理解的介绍，同时也是对围绕泛型的各种性能讨论的简单总结。首先，我们来看看泛型所解决的核心问题。
问题
假设我们想实现一个简单的 tree 数据结构。每个节点持有一个值。在 Go 1.18 之前，实现这种结构的典型方法如下。
type Node struct { value interface{} }
这在大多数情况下都很好用，但它也有一些缺点。
首先，interface{} 可以是任何东西。如果我们想限制 value 可能持有的类型，例如整数和浮点数，我们只能在运行时检查这个限制。
func (n Node) IsValid() bool { switch n.value.(type) { case int, float32, float64: return true default: return false } }
这样并不可能在编译时限制类型，像上面这样的类型判断在许多 Go 库中都是很常见的做法。这里有 go-zero 项目中的例子。
第二，对 Node 中的值进行处理是非常繁琐和容易出错的。对值做任何事情都会涉及到某种类型的断言，即使你可以安全地假设值持有一个 int 值。
number, ok := node.value.(int) if !ok { // ... } double := number * 2
这些只是使用 interface{} 的一些不便之处，它没有提供类型安全，并有可能导致难以恢复的运行时错误。
解决方法
我们不打算接受任意数据类型或具体类型，而是定义一个叫做 T 的 占位符类型 作为值的类型。请注意，这段代码还不会通过编译。
type Node[T] struct { value T }
首先需要声明泛型类型 T，这是在结构或函数名称后面方括号里面使用的。
T 可以是任何类型，只有在实例化一个具有明确类型的 Node 时，T 才会被推导为该类型。
n := Node[int]{ value: 5, }
泛型 Node 被实例化为 Node[int]（整数节点），所以 T 是一个 int。
类型约束
上面的实现里，T 的声明缺少一个必要的信息：类型约束。
类型约束用于进一步限制可以作为 T 的可能类型。Go 本身提供了一些预定义的类型约束，但也可以使用自定义的类型约束。
type Node[T any] struct { value T }
任意类型（any）约束允许 T 实际上是任何类型。如果节点值需要进行比较，有一个 comparable 类型约束，满足这个预定义约束的类型可以使用 == 进行比较。
type Node[T comparable] struct { value T }
任何类型都可以作为一个类型约束。Go 1.18 引入了一种新的 interface 语法，可以嵌入其他数据类型。
type Numeric interface { int | float32 | float64 }
这意味着一个接口不仅可以定义一组方法，还可以定义一组类型。使用 Numeric 接口作为类型约束，意味着值可以是整数或浮点数。
type Node[T Numeric] struct { value T }
重获类型安全
相对于使用 interface{}，泛型类型参数的巨大优势在于，T 的最终类型在编译时就会被推导出来。为 T 定义一个类型约束，完全消除了运行时检查。如果用作 T 的类型不满足类型约束，代码就不会编译通过。
在编写泛型代码时，你可以像已经知道 T 的最终类型一样写代码。
func (n Node[T]) Value() T { return n.value }
上面的函数返回 n.Value，它的类型是 T。因此，返回值是 T，如果 T 是一个整数，那么返回类型就已知是 int。因此，返回值可以直接作为一个整数使用，不需要任何类型断言。
n := Node[int]{ value: 5, } double := n.Value() * 2
在编译时恢复类型安全使 Go 代码更可靠，更不容易出错。
泛型使用场景
在 Ian Lance Taylor 的 When To Use Generics 中列出了泛型的典型使用场景，归结为三种主要情况：
- 使用内置的容器类型，如
slices、maps和channels - 实现通用的数据结构，如
linked list或tree - 编写一个函数，其实现对许多类型来说都是一样的，比如一个排序函数
一般来说，当你不想对你所操作的值的内容做出假设时，可以考虑使用泛型。我们例子中的 Node 并不太关心它持有的值。
当不同的类型有不同的实现时，泛型就不是一个好的选择。另外，不要把 Read(r io.Reader) 这样的接口函数签名改为 Read[T io.Reader](r T) 这样的通用签名。
性能
要了解泛型的性能及其在 Go 中的实现，首先需要了解一般情况下实现泛型的两种最常见方式。
这是对各种性能的深入研究和围绕它们进行的讨论的简要介绍。你大概率不太需要关心 Go 中泛型的性能。
虚拟方法表
在编译器中实现泛型的一种方法是使用 Virtual Method Table。泛型函数被修改成只接受指针作为参数的方式。然后，这些值被分配到堆上，这些值的指针被传递给泛型函数。这样做是因为指针看起来总是一样的，不管它指向的是什么类型。
如果这些值是对象，而泛型函数需要调用这些对象的方法，它就不能再这样做了。该函数只有一个指向对象的指针，不知道它们的方法在哪里。因此，它需要一个可以查询方法的内存地址的表格：Virtual Method Table。这种所谓的动态调度已经被 Go 和 Java 等语言中的接口所使用。
Virtual Method Table 不仅可以用来实现泛型，还可以用来实现其他类型的多态性。然而，推导这些指针和调用虚拟函数要比直接调用函数慢，而且使用 Virtual Method Table 会阻止编译器进行优化。
单态化
一个更简单的方法是单态化（Monomorphization），编译器为每个被调用的数据类型生成一个泛型函数的副本。
func max[T Numeric](a, b T) T { // ... } larger := max(3, 5)
由于上面显示的max函数是用两个整数调用的，编译器在对代码进行单态化时将为 int 生成一个 max 的副本。
func maxInt(a, b int) int { // ... } larger := maxInt(3, 5)
最大的优势是，Monomorphization 带来的运行时性能明显好于使用 Virtual Method Table。直接方法调用不仅更有效率，而且还能适用整个编译器的优化链。不过，这样做的代价是编译时长，为所有相关类型生成泛型函数的副本是非常耗时的。
Go 的实现
这两种方法中哪一种最适合 Go？快速编译很重要，但运行时性能也很重要。为了满足这些要求，Go 团队决定在实现泛型时混合两种方法。
Go 使用 Monomorphization，但试图减少需要生成的函数副本的数量。它不是为每个类型创建一个副本，而是为内存中的每个布局生成一个副本：int、float64、Node 和其他所谓的 "值类型" 在内存中看起来都不一样，因此泛型函数将为所有这些类型复制副本。
与值类型相反，指针和接口在内存中总是有相同的布局。编译器将为指针和接口的调用生成一个泛型函数的副本。就像 Virtual Method Table 一样，泛型函数接收指针，因此需要一个表来动态地查找方法地址。在 Go 实现中的字典与虚拟方法表的性能特点相同。
结论
这种混合方法的好处是，你在使用值类型的调用中获得了 Monomorphization 的性能优势，而只在使用指针或接口的调用中付出了 Virtual Method Table 的成本。
在性能讨论中经常被忽略的是，所有这些好处和成本只涉及到函数的调用。通常情况下，大部分的执行时间是在函数内部使用的。调用方法的性能开销可能不会成为性能瓶颈，即使是这样，也要考虑先优化函数实现，再考虑调用开销。
更多阅读
Vicent Marti: Generics can make your Go code slower (PlanetScale)
Andy Arthur: Generics and Value Types in Golang (Dolthub)
Virtual method table (Wikipedia)
Monomorphization (Wikipedia)
Dynamic dispatch (Wikipedia)
对标准库的影响
作为 Go 1.18 的一部分，不改变标准库 是一个谨慎的决定。目前的计划是收集泛型的经验，学习如何适当地使用它们，并在标准库中找出合理的用例。
Go 有一些关于通用包、函数和数据结构的提议：
constraints, providing type constraints (#47319)maps, providing generic map functions (#47330)slices, providing generic slice functions (#47203)sort.SliceOf, a generic sort implementation (#47619)sync.PoolOfand other generic concurrent data structures (#47657)
关于 go-zero 泛型的计划
对 go-zero 支持用泛型改写，我们持谨慎态度，因为一旦使用泛型，那么 Go 版本必须从 1.15 升级到 1.18，很多用户的线上服务现在还未升级到最新版，所以 go-zero 的泛型改写会延后 Go 两三个版本，确保用户线上服务大部分已经升级到 Go 1.18
go-zero 也在对泛型做充分的调研和尝试。
其中的 mr 包已经新开仓库支持了泛型：
https://github.com/kevwan/mapreduce
其中的 fx 包也已新开仓库尝试支持泛型，但是由于缺少 template method，未能完成，期待后续 Go 泛型的完善
https://github.com/kevwan/stream
当后续 go-zero 支持泛型的时候，我们就会合入这些已经充分测试的泛型实现。
