Go 博客

何时使用泛型

Ian Lance Taylor
2022 年 4 月 12 日

引言

这是我在 Google 开源直播会议上的演讲的博客文章版本

以及 GopherCon 2021 会议

Go 1.18 版本增加了一个主要的新语言特性：支持泛型编程。在本文中，我不会描述泛型是什么或如何使用它们。本文是关于何时在 Go 代码中使用泛型以及何时不使用泛型。

需要明确的是，我将提供一般性指导，而不是死板的规则。请自行判断。但如果您不确定，我建议遵循此处讨论的指导。

编写代码

让我们从 Go 编程的一般性指导开始：通过编写代码来编写 Go 程序，而不是通过定义类型。说到泛型，如果您通过定义类型参数约束来开始编写程序，您很可能走错了路。从编写函数开始。当类型参数的用途明确时，稍后再添加它们很容易。

类型参数何时有用？

话虽如此，让我们看看类型参数可能有用的情况。

使用语言定义的容器类型时

一种情况是编写操作语言定义的特殊容器类型（切片、映射和通道）的函数时。如果一个函数的参数具有这些类型，并且函数代码对元素类型没有任何特定假设，那么使用类型参数可能很有用。

例如，这里有一个函数，它返回任何类型映射中的所有键的切片

// MapKeys returns a slice of all the keys in m.
// The keys are not returned in any particular order.
func MapKeys[Key comparable, Val any](m map[Key]Val) []Key {
    s := make([]Key, 0, len(m))
    for k := range m {
        s = append(s, k)
    }
    return s
}

这段代码对映射键类型没有任何假设，并且完全不使用映射值类型。它适用于任何映射类型。这使得它成为使用类型参数的良好候选。

对于这类函数，类型参数的替代方案通常是使用反射，但这是一种更笨拙的编程模型，在构建时不会进行静态类型检查，并且在运行时通常更慢。

通用数据结构

类型参数可能有用的另一种情况是通用数据结构。通用数据结构类似于切片或映射，但不是语言内置的，例如链表或二叉树。

今天，需要这种数据结构的程序通常会做两件事之一：用特定的元素类型编写它们，或使用接口类型。用类型参数替换特定元素类型可以生成更通用的数据结构，可在程序的其他部分或由其他程序使用。用类型参数替换接口类型可以更有效地存储数据，节省内存资源；它还可以使代码避免类型断言，并在构建时进行完全类型检查。

例如，这里是用类型参数实现二叉树数据结构的一部分可能的样子

// Tree is a binary tree.
type Tree[T any] struct {
    cmp  func(T, T) int
    root *node[T]
}

// A node in a Tree.
type node[T any] struct {
    left, right  *node[T]
    val          T
}

// find returns a pointer to the node containing val,
// or, if val is not present, a pointer to where it
// would be placed if added.
func (bt *Tree[T]) find(val T) **node[T] {
    pl := &bt.root
    for *pl != nil {
        switch cmp := bt.cmp(val, (*pl).val); {
        case cmp < 0:
            pl = &(*pl).left
        case cmp > 0:
            pl = &(*pl).right
        default:
            return pl
        }
    }
    return pl
}

// Insert inserts val into bt if not already there,
// and reports whether it was inserted.
func (bt *Tree[T]) Insert(val T) bool {
    pl := bt.find(val)
    if *pl != nil {
        return false
    }
    *pl = &node[T]{val: val}
    return true
}

树中的每个节点都包含类型参数 T 的值。当树用特定的类型实参实例化时，该类型的值将直接存储在节点中。它们不会存储为接口类型。

这是类型参数的合理用法，因为 Tree 数据结构，包括方法中的代码，很大程度上独立于元素类型 T。

Tree 数据结构确实需要知道如何比较元素类型 T 的值；它为此使用传入的比较函数。您可以在 find 方法的第四行，在调用 bt.cmp 中看到这一点。除此之外，类型参数根本不重要。

对于类型参数，优先使用函数而非方法

Tree 示例说明了另一个一般性指导：当您需要比较函数之类的东西时，优先选择函数而非方法。

我们可以定义 Tree 类型，使其元素类型必须具有 Compare 或 Less 方法。这将通过编写一个要求该方法的约束来实现，这意味着任何用于实例化 Tree 类型的类型实参都需要具有该方法。

结果是，任何想将 Tree 与 int 等简单数据类型一起使用的人都必须定义自己的整数类型并编写自己的比较方法。如果我们将 Tree 定义为接受一个比较函数，如上面显示的代码所示，那么很容易传入所需的函数。编写那个比较函数就像编写一个方法一样容易。

如果 Tree 元素类型恰好已经有一个 Compare 方法，那么我们可以简单地使用像 ElementType.Compare 这样的方法表达式作为比较函数。

换句话说，将方法转换为函数比向类型添加方法简单得多。因此，对于通用数据类型，优先选择函数，而不是编写要求方法的约束。

实现一个通用方法

类型参数可能有用的另一种情况是，当不同类型需要实现某个通用方法，并且不同类型的实现看起来完全相同时。

例如，考虑标准库的 sort.Interface。它要求一个类型实现三个方法：Len、Swap 和 Less。

这里是一个泛型类型 SliceFn 的示例，它为任何切片类型实现了 sort.Interface

// SliceFn implements sort.Interface for a slice of T.
type SliceFn[T any] struct {
    s    []T
    less func(T, T) bool
}

func (s SliceFn[T]) Len() int {
    return len(s.s)
}
func (s SliceFn[T]) Swap(i, j int) {
    s.s[i], s.s[j] = s.s[j], s.s[i]
}
func (s SliceFn[T]) Less(i, j int) bool {
    return s.less(s.s[i], s.s[j])
}

对于任何切片类型，Len 和 Swap 方法是完全相同的。Less 方法需要一个比较，这是 SliceFn 名称的 Fn 部分。与前面的 Tree 示例一样，我们在创建 SliceFn 时将传入一个函数。

这里是如何使用 SliceFn 通过比较函数对任何切片进行排序

// SortFn sorts s in place using a comparison function.
func SortFn[T any](s []T, less func(T, T) bool) {
    sort.Sort(SliceFn[T]{s, less})
}

这类似于标准库函数 sort.Slice，但比较函数是使用值而不是切片索引编写的。

对这类代码使用类型参数是合适的，因为所有切片类型的方法看起来完全相同。

（我应该提到，Go 1.19——而不是 1.18——很可能会包含一个泛型函数，用于使用比较函数对切片进行排序，并且该泛型函数很可能不使用 sort.Interface。请参阅提案 #47619。但即使这个具体示例很可能没有用，一般性的观点仍然是正确的：当您需要实现对于所有相关类型看起来相同的方法时，使用类型参数是合理的。）

类型参数何时无用？

现在让我们谈谈问题的另一面：何时不使用类型参数。

不要用类型参数替换接口类型

众所周知，Go 有接口类型。接口类型允许一种泛型编程。

例如，广泛使用的 io.Reader 接口提供了一种通用机制，用于从任何包含信息（例如文件）或产生信息（例如随机数生成器）的值读取数据。如果您只需要对某种类型的值执行的操作是调用该值上的方法，请使用接口类型，而不是类型参数。io.Reader 易于阅读、高效且有效。无需使用类型参数通过调用 Read 方法从值中读取数据。

例如，将这里的第一个函数签名（只使用接口类型）更改为第二个版本（使用类型参数）可能很诱人。

func ReadSome(r io.Reader) ([]byte, error)

func ReadSome[T io.Reader](r T) ([]byte, error)

不要进行这种更改。省略类型参数会使函数更容易编写、更容易阅读，并且执行时间很可能相同。

值得强调最后一点。虽然可以通过几种不同的方式实现泛型，并且实现会随着时间而改变和改进，但在 Go 1.18 中使用的实现在许多情况下会将类型为类型参数的值与类型为接口类型的值非常相似地处理。这意味着使用类型参数通常不会比使用接口类型更快。因此，不要仅仅为了速度而从接口类型改为类型参数，因为它可能不会运行得更快。

如果方法实现不同，请勿使用类型参数

在决定是使用类型参数还是接口类型时，请考虑方法的实现。前面我们说过，如果方法的实现对于所有类型都是相同的，则使用类型参数。反之，如果实现对于每种类型都不同，则使用接口类型并编写不同的方法实现，不要使用类型参数。

例如，从文件读取 Read 的实现与从随机数生成器读取 Read 的实现完全不同。这意味着我们应该编写两个不同的 Read 方法，并使用像 io.Reader 这样的接口类型。

在适当的地方使用反射

Go 有 运行时反射。反射允许一种泛型编程，因为它允许您编写适用于任何类型的代码。

如果某些操作必须支持即使没有方法的类型（因此接口类型无济于事），并且如果操作对于每种类型都不同（因此类型参数不合适），请使用反射。

一个例子是 encoding/json 包。我们不希望要求我们编码的每个类型都有一个 MarshalJSON 方法，所以我们不能使用接口类型。但是编码接口类型与编码结构类型完全不同，所以我们不应该使用类型参数。相反，该包使用反射。代码不简单，但它有效。有关详细信息，请参阅 源代码。

一个简单指导

最后，何时使用泛型的讨论可以归结为一个简单的指导。

如果您发现自己多次编写完全相同的代码，而副本之间的唯一区别在于代码使用了不同的类型，请考虑是否可以使用类型参数。

另一种说法是，您应该避免使用类型参数，直到您注意到自己即将多次编写完全相同的代码。