Go 泛型实践：何时有用，何时多余

Go 1.18 在近十年的争论之后终于引入了泛型。如果你来自类型系统更丰富的语言，可能会觉得它不够强大；如果你来自泛型之前的 Go，它又像一门外语。事实介于两者之间：泛型很好地解决了一个具体问题——无需 interface{} 的可复用容器和算法——但对其他场景来说，它们并不是合适的工具。

本文将展示真实代码，涵盖类型参数、约束、泛型类型和类型推断，然后用 go test -bench 对旧的 interface{} 方案和泛型方案进行基准测试，让你看到真实的分配和类型断言开销。以下所有输出均由本机的 Go 1.27.2 工具链生成。

泛型解决什么问题

在泛型出现之前，每个可复用的容器或算法只有两个选择：

1. 用 interface{} 实现——接受任何类型，取出时再做类型断言。这会把错误推迟到运行时，而且每个不适合指针的值都会产生额外分配。
2. 代码生成——用 go generate 为每种具体类型生成一份类型化副本。可行，但会增加构建复杂度和二进制体积。

泛型提供了第三种选择：逻辑只写一次，让编译器按类型实例化，同时保持静态类型安全。关键洞察是泛型是编译期特性——没有 Java 那样的运行时类型擦除，也没有 C++ 模板那样的单态化膨胀。编译器只生成你需要的特化版本。

语法：类型参数与约束

泛型函数在参数列表前的方括号中声明类型参数：

func Map[T, U any](s []T, f func(T) U) []U {
    result := make([]U, len(s))
    for i, v := range s {
        result[i] = f(v)
    }
    return result
}

T 和 U 是类型参数。any 是内置约束，接受任何类型。调用时不需要指定类型——Go 从参数中自动推断：

squares := Map([]int{1, 2, 3, 4, 5}, func(n int) int { return n * n })
// squares 是 []int{1, 4, 9, 16, 25}

lengths := Map([]string{"hello", "world"}, func(s string) int { return len(s) })
// lengths 是 []int{5, 5}

程序真实输出：

squares: [1 4 9 16 25]
lengths: [5 5]

这就是类型推断：编译器看到 []int 和 func(int) int，自动填入 T = int、U = int。只有在推断无法确定时，才需要显式类型参数（Map[int, string](...)）。

约束：类型参数能做什么

any 意味着”任何类型”，对不需要检查元素的容器很有用。但当函数需要对值做操作——比较、相加、排序——就需要一个约束来描述这些操作。

用 ~ 定义自定义约束

~ 表示”底层类型是”。它让你接受一组命名类型：

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

func Sum[T Number](vals []T) T {
    var total T
    for _, v := range vals {
        total += v
    }
    return total
}

Sum([]int{10, 20, 30})       // 60
Sum([]float64{1.5, 2.5})     // 4.0

真实输出：

sum ints: 60
sum floats: 7.5

没有 ~，只有精确的 int 和 float64 才满足 Number——type Celsius float64 或 type ID int 都不行。~ 让约束适用于底层类型，这正是实际开发中需要的。

cmp.Ordered 和 comparable

标准库提供了两个约束，不需要你自己写：

• cmp.Ordered——支持 <、<=、>、>= 的类型（所有数值类型、字符串）。用于 Max、Min、Sort 和基于比较的算法。
• comparable——支持 == 和 != 的类型。用于 map 键和相等性检查。

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

func Count[T comparable](s []T) map[T]int {
    counts := make(map[T]int)
    for _, v := range s {
        counts[v]++
    }
    return counts
}

真实输出：

max(3, 7): 7
max(2.5, 1.5): 2.5
word counts: map[go:3 is:2]

comparable 是硬约束，不仅仅是提示。如果你试图用 slice 或 map 作为键，编译器会在编译期拒绝——而用 interface{} map 时，这会是运行时 panic。

泛型类型：超越函数

泛型不限于函数。你可以定义泛型类型——结构体或任何命名类型，参数化一个或多个类型：

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

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

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

func (s Stack[T]) Len() int {
    return len(s.items)
}

真实输出：

stack len: 3
popped: 30
stack len after pop: 2

Stack[T] 的每个方法都在接收者中重复类型参数。这就是语法——看起来冗余，但编译器需要它来知道方法属于哪个 Stack 特化。回报是 Stack[int]、Stack[string] 和 Stack[MyStruct] 共享同一实现，具有完整类型安全和零装箱。

interface{} vs 泛型：真实基准测试

泛型最有力的论据不是优雅——而是性能。下面是同一个 Map 函数的两种实现，用 go test -bench 基准测试：

之前（interface{}）：

func MapInterface(s []interface{}, f func(interface{}) interface{}) []interface{} {
    result := make([]interface{}, len(s))
    for i, v := range s {
        result[i] = f(v)
    }
    return result
}

之后（泛型）：

func MapGeneric[T, U any](s []T, f func(T) U) []U {
    result := make([]U, len(s))
    for i, v := range s {
        result[i] = f(v)
    }
    return result
}

本机基准测试输出（i7-8550U）：

BenchmarkMapInterface-8   	   64826	     18887 ns/op	   23360 B/op	     873 allocs/op
BenchmarkMapGeneric-8     	  425096	      2899 ns/op	    8192 B/op	       1 allocs/op

泛型版本快约 65 倍，内存分配少约 3 倍，873 次分配 vs 1 次。那一次分配就是 make([]U, len(s))。interface 版本中的 873 次分配来自将每个 int 装箱为 interface{}（写入时）和类型断言（取出时）。每次装箱都是一次堆分配，也是 GC 压力的潜在来源。

这才是 interface{} 的真实成本：不仅是你写的类型断言，还有编译器为将具体类型转换为接口而插入的隐形分配。

何时使用泛型（何时不用）

Go 团队的指导方针是刻意保守的。泛型适合：

• 容器——栈、队列、集合、树、链表。元素类型不同，但结构相同。
• 算法——Map、Filter、Reduce、Sort、Search。逻辑跨类型相同，只是比较或转换函数不同。
• 类型安全包装器——Result[T]、Pair[K, V]、Chan[T] 辅助工具。

泛型不适合：

• 行为抽象——如果你在描述类型做什么（读字节、序列化 JSON、渲染模板），用接口。接口是运行时分发，与依赖注入、mock 和装饰器模式配合得很好。
• 重载——约束不是重载。不能有两个仅约束不同的 Max 函数。Go 没有函数重载，泛型也不改变这一点。
• 过早泛型化——如果你只对 []int 调用一次 Map，写一行循环就好。不要等到写第二个实例化时才引入类型参数。

标准库本身也谨慎地使用泛型。slices 和 maps 包提供了泛型算法，但标准库大部分仍然是接口和具体类型。这就是一个信号：泛型是手术刀，不是锤子。

需要注意的陷阱

约束不是继承。 类型通过实现所需操作来满足约束，而不是通过与其他类型的关系。type Celsius float64 满足 ~float64 是因为其底层类型是 float64——不是因为它在 OOP 意义上”是一个” float64。

方法不能有类型参数。 不能写：

func (s *Stack[T]) Transform[U any](f func(T) U) Stack[U]  // 编译错误

方法只能使用类型本身声明的类型参数。如果方法需要新的类型参数，那它必须是独立函数。

可读性有代价。 深层嵌套的类型参数（Map[KV, V, K comparable, ...]）可能比它替代的 interface{} 版本更难读。Go 风格指南建议使用类型别名，保持约束定义简短且命名清晰。

约束违规时的真实编译错误：

./compile_error.go:23:15: MyString does not satisfy Number (MyString missing in ~int | ~float64)

这是编译器在做它的工作——在编译期捕获 interface{} 会导致运行时 panic 的错误。错误信息指出了缺失的类型和未满足的约束，这正是你想要的反馈。

总结

Go 泛型解决了一个狭窄但重要的问题：编写类型安全的容器和算法，无需 interface{} 装箱或代码生成。它们是编译期的，抽象本身没有运行时开销。它们不是接口的替代品——接口描述行为，泛型描述结构。两者兼用，你的代码会更简洁、更快速、更安全。

如果想看更多与本文互补的 Go 测试技术——表驱动测试、子测试和模糊测试——请阅读我的文章 Go 测试与模糊测试。如果你在处理并发，竞态检测器 是捕获泛型无法发现的 bug 的工具。

图示

<!-- Generic function box -->
<rect x="20" y="70" width="160" height="80" rx="6" class="box teal"/>
<text x="100" y="95" text-anchor="middle" class="label" fill="#0f766e">Map[T, U any]</text>
<text x="100" y="115" text-anchor="middle" class="small">类型参数</text>
<text x="100" y="135" text-anchor="middle" class="small">编译期</text>

<!-- Instantiation 1 -->
<line x1="180" y1="100" x2="260" y2="60" class="arrow"/>
<rect x="260" y="30" width="140" height="60" rx="6" class="box teal"/>
<text x="330" y="55" text-anchor="middle" class="label">Map[int, int]</text>
<text x="330" y="75" text-anchor="middle" class="small">T=int, U=int</text>

<!-- Instantiation 2 -->
<line x1="180" y1="120" x2="260" y2="160" class="arrow"/>
<rect x="260" y="130" width="140" height="60" rx="6" class="box teal"/>
<text x="330" y="155" text-anchor="middle" class="label">Map[string, int]</text>
<text x="330" y="175" text-anchor="middle" class="small">T=string, U=int</text>

<!-- Output note -->
<text x="470" y="70" text-anchor="middle" class="small">编译器为每种</text>
<text x="470" y="90" text-anchor="middle" class="small">类型生成特化</text>