Go sort 包的设计模式：从 Interface 到 Slice 到泛型 Sort 的演进

排序大概是业务代码里出现频率最高、也最容易被当成“调标准库就行”的功能。但如果你认真看过 Go 标准库 sort 包的 API 变迁，会发现它像一面镜子，照出了 Go 语言这些年设计取向的变化：从 Go 1.0 的接口抽象，到 Go 1.8 的反射妥协，再到 Go 1.21 泛型带来的重构。这不仅是语法层面的简化，三代方案在类型安全、运行性能和代码表达力上，作出了完全不同的取舍。

很多团队会遇到同一个问题：项目里既有实现了 sort.Interface 的老代码，也有大量 sort.Slice 调用，升级到 Go 1.21 之后又有人开始推荐新的泛型 Sort。到底该用哪个？新的泛型排序是不是一定更快？这篇文章把三代设计逐一拆开，讲清楚它们背后的动机、代价和适用场景。

第一代 sort.Interface：先定契约，再谈算法

Go 1.0 发布时，sort 包的核心抽象是一个只有三个方法的接口：

type Interface interface {
    Len() int
    Less(i, j int) bool
    Swap(i, j int)
}

排序算法不关心底层数据结构是什么，它只依赖三件事：集合有多大、两个元素谁该在前、怎么交换两个元素。这种设计的最大好处是算法与容器解耦，理论上你甚至可以用它去排序一个链表实现的集合，只要能实现这三个方法。

实际写起来是这个样子：

type Person struct {
    Name string
    Age  int
}

type ByAge []Person

func (p ByAge) Len() int           { return len(p) }
func (p ByAge) Less(i, j int) bool { return p[i].Age < p[j].Age }
func (p ByAge) Swap(i, j int)      { p[i], p[j] = p[j], p[i] }

sort.Sort(ByAge(people))

这段代码放到今天看，最直观的问题就是“重”。每自定义一个排序维度，就要定义一个新类型、实现三个方法。后台管理系统的列表页是最典型的场景：接口返回一个 []User，产品需求每隔一两周就换一次排序维度，这周按注册时间倒序，下周按最后登录时间排。用 sort.Interface 的思路写下去，代码里很快就会堆出一堆 ByXXX 类型，它们之间往往只是 Less 函数的几行差异，重复感极强。

但反过来讲，接口设计也给了其他方案没有的东西。sort.Reverse 通过包装 Less 的语义就能实现反向排序，sort.Stable 可以独立选择稳定排序算法，而且整个过程没有任何反射开销，性能模型非常干净。这几个优点在后来的 sort.Slice 上反而丢失了一部分。

第二代 sort.Slice：用反射换来的便利

Go 1.8 引入 sort.Slice，其目标简单直接：简化排序代码。它接受任意 slice 和一个闭包形式的 less 函数：

sort.Slice(people, func(i, j int) bool {
    return people[i].Age < people[j].Age
})

不需要定义类型，不需要写 Len 和 Swap，排序维度直接写在闭包里，甚至可以顺手写多级比较逻辑。这个 API 一出现就迅速取代 sort.Interface，成为 Go 代码库里的主流写法，原因很简单：它解决的是实际痛点，不是抽象美感。

但便利是有代价的。sort.Slice 要在运行时通过反射确认参数确实是 slice，再用 reflect.Swapper 完成元素交换，每次交换都会引入比普通元组赋值大得多的开销。以基础类型排序为例，sort.Slice 通常比实现了 sort.Interface 的风格慢一个明显的常数倍。

真正麻烦的地方在于，这些代价是隐性的。项目初期数据量小，感受不到差别；一旦某个热点接口的排序调用频率上来，CPU 开销就会变得刺眼。我见过一个监控数据的聚合服务，数据量只有几千条，但每秒要排几十次，sort.Slice 的反射开销把 CPU 明显抬高，改成适配 sort.Interface 的类型后才降下来。这不是说 sort.Slice 不能用，而是要知道它的性能边界在哪里。

另一个问题是类型安全。sort.Slice 的签名是 sort.Slice(slice interface{}, less func(i, j int) bool)，参数类型是空接口，编译期拦不住任何错误输入。一旦传入的不是 slice，只能在运行时 panic；闭包捕获错误变量这类问题也完全暴露在开发者面前。这些不算 API 设计失误，而是当时没有泛型，反射是唯一能让调用方少写代码的路径。

第三代泛型 Sort：类型安全与性能一起回归

Go 1.21 带来了基于泛型的排序 API，分别落在 sort 包的新增函数和 slices 包上。最常见的写法是这两类：

import (
    "cmp"
    "slices"
)

// 基础类型直接排
slices.Sort(ages)

// 结构体使用比较函数
slices.SortFunc(people, func(a, b Person) int {
    return cmp.Compare(a.Age, b.Age)
})

注意到比较函数从 bool 换成了 int，这是一个值得细品的语义变化。Less 风格只表达“谁在前”，int 风格的比较器同时表达谁在前、谁在后、还是相等（返回 0）。这让调用方能更自然地描述排序方向，也让标准库的 cmp.Compare 有了用武之地。

泛型版本在编译期就知道元素的真实类型，不需要反射，不存在运行时的类型断言失败。编译器可以把比较函数内联进排序循环，标准库又为基础类型准备了专门的快速排序路径，因此它并不是旧接口的语法糖包装，而是一次真正的性能回归。对 Go 1.21 之后的新代码，直接用 slices.Sort 处理基础类型切片，或用 slices.SortFunc 处理结构体，几乎总是最优选。

三代方案怎么选：一张表看明白

需要强调的是，三代 API 在标准库中是共存的，Go 的兼容性承诺保证了旧代码不会被破坏。这个表的意义不是号召你立刻淘汰旧写法，而是在写新代码时做选择。

几个容易踩的坑

无论用哪一代 API，下面这些误区的本质都一样，只是表现形式略有差别。

• 默认排序不稳定。sort.Slice 用的是快速排序变体，不稳定。如果业务依赖“相等元素保持原始顺序”，必须显式使用 sort.SliceStable 或 slices.SortStableFunc。稳定性是有代价的，它需要额外的内存和比较次数，不要无条件使用。
• 比较逻辑必须满足严格弱序。Less 或 compare 函数不能自相矛盾，否则排序结果不可预期。最常见的来源是浮点 NaN，它在任何比较中都返回 false，含 NaN 的 float64 切片直接排序，结果会非常诡异。基准测试里可以先筛选掉非有限数。
• sort.Slice 的入参是空接口。传入非 slice 只能在运行时 panic。尽量把排序调用放在数据路径清晰的地方，不要在层层回调里绕了一圈才调用。
• bool 和 int 的返回值差异。从 sort.Slice 迁移到 slices.SortFunc 时，如果还按 Less 的习惯写 return a.Age < b.Age，会直接编译失败，因为布尔值不能充当 int。正确写法是用 cmp.Compare 包一层。
• 降序别用取反硬来。sort.Slice 时代有人用 !less(i, j) 实现降序，大多数情况能用，但会让相等元素的处理语义变模糊。泛型时代直接调换比较参数即可：cmp.Compare(b.Age, a.Age)，语义一目了然。

落地建议：新代码与存量代码各自怎么办

如果你在写新项目，Go 版本在 1.21 以上，直接全面使用 slices.Sort 和 slices.SortFunc，不用犹豫。它同时满足类型安全、性能和表达力，没有明显短板。

如果项目里已有大量 sort.Slice 调用，我不建议大动干戈全部替换，除非你确实测出了性能问题。排序逻辑分散在几十个文件里，逐一手工重写，收益未必能覆盖回归风险。更务实的做法是分三步走：

1. 先给排序热点路径写基准测试，确认 sort.Slice 的开销占比是否值得优化；
2. 只替换确实有问题的热点代码，顺手补充单元测试；
3. 非热点代码保持原样，等下一次涉及它的重构时再顺手迁移。

如果你在维护公共工具库，问题会多一层：用户可能还停留在 Go 1.20 或更早。这时候直接使用 slices.SortFunc，等于放弃了这些用户。折中方案是继续提供接受比较函数的 API，内部用构建标签配合泛型和旧实现各维护一套。标准库自己就是这么处理的，旧 API 全部保留，新函数通过泛型叠加。

一句话总结：排序 API 的选择，本质上是在表达力、运行时开销和兼容性之间做权衡。Go 1.21 之后，泛型把三者重新平衡到了一个更好的位置，但这不意味着旧方案没有价值，尤其是面对存量代码时。

从 sort 包演进，看 Go 库设计的方法论

把三代 API 放在一起看，能明显感受到 Go 标准库对“什么样的库 API 好用”这件事的理解在变化。Interface 时代是抽象优先，把排序算法需要的三个操作提炼成契约，强调算法与数据结构的解耦；Slice 时代是实用性优先，用反射换取调用方的少量代码；泛型时代则是安全与性能的回归，让表达力不再以牺牲编译期检查为代价。

对普通 Go 工程师来说，这个故事最大的价值或许不是记住函数签名，而是建立一种设计判断力：当你设计一个通用算法库时，接受一个比较函数往往比强制用户实现接口更友好。C++ 的 std::sort 和 Rust 的 sort_by 都印证了这条路，而 Go 泛型的到来，让你在设计自己的库时也多了一个更自然的选择。

排序是入门算法，sort 包也只是标准库的一个角落，但 Go 语言十来年的设计积累，恰恰浓缩在了这三个 API 形态里。理解了这条演进线，再去看标准库的其他泛型重构，比如 maps、slices 下的工具函数，会顺畅很多。