Go 多级排序实战：sort.Interface、稳定排序与泛型封装

1. 从一次业务需求说起：为什么 Go 的排序这么“麻烦”

先说我最近遇到的一件事。后台管理系统要导出一张订单列表，排序规则大概是这样的：先按订单状态分组，状态相同就按金额降序，金额也一样就按创建时间升序，最后再用订单号兜底，保证分页稳定不乱跳。

你写代码的时候大概也发现了，Go 的sort包跟很多语言的排序不太一样。Java 里有Comparator链式调用，Python 有key参数能传sorted，甚至 JavaScript 的array.sort((a,b)=>a.foo - b.foo || a.bar - b.bar)一行就搞定了。但 Go 里最简单的方式是实现sort.Interface，把Len、Less、Swap三个方法写出来。很多新手第一次接触会觉得很别扭，明明那么简单的排序需求，怎么要写这么多代码。

但我想说的是，这个“麻烦”恰恰是 Go 设计上的亮点。sort.Interface让你把排序的规则和数据结构彻底解耦，排序算法在sort包里是通用的，你只需要告诉它“什么叫做一个元素在另一个元素之前”。一旦想通了这个模型，复杂排序不但不难写，反而比那种链式 Comparator 更容易排查问题、更容易扩展规则、也更容易写测试。

这篇文章我要聊的就是这件事：用sort.Interface实现复杂多级排序的完整套路。包括基础姿势、多种多级排序的实现思路、稳定排序的重要性、性能问题，以及一些我在实际项目中踩过的坑。

先说结论：多级排序的核心就一句话——在Less方法里按优先级逐级比较，每一级要么返回结果，要么继续比下一级。

2. 先把基础打牢：sort.Interface 是什么，以及它为什么这么设计

2.1 三个方法背后是“三件事”

sort.Interface长这样：

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

它只规定了三件事：集合有多大、两个元素谁更“小”、以及怎么交换两个元素的位置。至于用的是什么排序算法——那是sort.Sort的事情，你完全不关心。sort.Sort在压缩最近临被调用时可能看不出来，但实际上它内部用的是快速排序、堆排序和插入排序的混合方案，专门为这个接口优化的。

一个最普通的例子，给整数切片排序：

type IntSlice []int func (s IntSlice) Len() int { return len(s) } func (s IntSlice) Less(i, j int) bool { return s[i] < s[j] } func (s IntSlice) Swap(i, j int) { s[i], s[j] = s[j], s[i] } func main() { nums := IntSlice{3, 1, 4, 1, 5, 9, 2, 6} sort.Sort(nums) fmt.Println(nums) // [1 1 2 3 4 5 6 9] }

你可能会问：标准库不是已经提供了sort.Ints和sort.Slice吗？为什么还要自己写IntSlice？没错，简单场景确实用不上，sort.Slice一个函数就解决了：

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

但Interface的价值不在简单场景，而在复杂场景。当你需要可复用的排序规则、需要多级比较、需要在不同数据结构之间共享同一套排序逻辑的时候，Interface的优势才会完全体现出来。

2.2 理解 Less 是理解一切的关键

Less(i, j int) bool的语义是：i位置的元素是否应该排在j位置的元素前面。这个“前面”不一定是数值小，而是你业务上定义的前后关系。

有个很重要的细节：Less隐含了严格弱序的要求。什么意思？你自己定义的比较规则必须满足几个数学上的性质，比如不存在“自己比自己小”的情况，比如Less(a, b)和Less(b, a)不能同时为 true。如果你写反了或者没写全，排序结果会非常诡异。

还有一条容易被忽略的规则：当两个元素完全相等时，Less必须返回false。如果相等还返回true，排序算法会认为“前者必须在后者前面”，导致两个相等的元素不断交换位置，轻则顺序不稳定，重则影响性能甚至导致异常。

2.3 一个关键认知：Less 的三个返回值拆解

这里给你一个我常用的思考框架：写比较逻辑的时候，把Less当成一个“比较函数”来写。这个思想来源于 C 语言的三方比较，但是 Go 里Less的返回值只有 true 和 false。按照惯例，比较函数会做三件事：

• a < b，返回 true，表示 a 排在 b 前。
• a > b，返回 false，表示 b 排在 a 前。
• a == b，返回 false，表示两者等价，顺序无所谓。

如果只有一个比较字段，这就是全部逻辑。但多级排序就复杂在这里——副比较字段只有在主比较字段全相等的情况下才“说得上话”。所以你的代码逻辑应该是：

if a.Primary != b.Primary { return a.Primary < b.Primary } return a.Secondary < b.Secondary

先做主字段比较，能分出高低就直接返回；分不出来，再去做次字段比较。这正是多级排序的本质。

注意：相等情况（Primary相等）不能简单返回false就结束，你需要接着比较二级字段。很多新手在这里栽跟头——一级字段相等时直接 return 了，导致相等的元素不再根据二级字段排序。

3. 多级排序的三种实现思路，从“最笨”到“最优雅”

3.1 思路一：Less 里嵌套多层级比较

这是最直觉的写法。一个订单结构体，我们按“状态升序、金额降序、时间升序、ID升序”四级排序，代码长这样：

type Order struct { ID int64 Status int Amount float64 CreatedAt time.Time } type OrderSlice []Order func (s OrderSlice) Len() int { return len(s) } func (s OrderSlice) Less(i, j int) bool { // 第一级：状态升序 if s[i].Status != s[j].Status { return s[i].Status < s[j].Status } // 第二级：金额降序 if s[i].Amount != s[j].Amount { return s[i].Amount > s[j].Amount } // 第三级：创建时间升序 if !s[i].CreatedAt.Equal(s[j].CreatedAt) { return s[i].CreatedAt.Before(s[j].CreatedAt) } // 第四级：ID 升序，作为最终兜底 return s[i].ID < s[j].ID } func (s OrderSlice) Swap(i, j int) { s[i], s[j] = s[j], s[i] }

这种写法有两个好处。第一，逻辑直白，维护的人一眼就能看出排序优先级。第二，每一级都不需要什么花哨技巧，就是基础的比较判断。

但它的缺点也很明显：当排序维度很多、条件逻辑很长的时候，这个Less方法会迅速膨胀。比如你有五个字段要排序，每个字段还有升降序和空值处理规则，这个函数很快就会写到一百多行。而且不同实体之间的公共比较逻辑无法复用。

3.2 思路二：把比较器拆成独立的函数

既然一级一级的比较本质上是一个“按照优先级依次判断”的过程，我们可以把每一级的判断逻辑抽出来，让代码更清晰。

先定义一个比较函数类型，返回值用 int 表示三态：负数表示小于，0 表示等于，正数表示大于。

type CmpFunc func(i, j int) int

然后写一个通用骨架，把一组比较器串起来：

type MultiSorter struct { len int swap func(i, j int) cmps []CmpFunc } func (m *MultiSorter) Len() int { return m.len } func (m *MultiSorter) Swap(i, j int) { m.swap(i, j) } func (m *MultiSorter) Less(i, j int) bool { for _, cmp := range m.cmps { if r := cmp(i, j); r != 0 { return r < 0 } } return false }

接下来，每一个比较器都是独立的函数，职责单一：

func cmpStatusAsc(s []Order) CmpFunc { return func(i, j int) int { return s[i].Status - s[j].Status } } func cmpAmountDesc(s []Order) CmpFunc { return func(i, j int) int { if s[i].Amount > s[j].Amount { return -1 } if s[i].Amount < s[j].Amount { return 1 } return 0 } } func cmpTimeAsc(s []Order) CmpFunc { return func(i, j int) int { if s[i].CreatedAt.Before(s[j].CreatedAt) { return -1 } if s[i].CreatedAt.After(s[j].CreatedAt) { return 1 } return 0 } }

使用的时候，按优先级传入：

ms := &MultiSorter{ len: len(orders), swap: func(i, j int) { orders[i], orders[j] = orders[j], orders[i] }, cmps: []CmpFunc{ cmpStatusAsc(orders), cmpAmountDesc(orders), cmpTimeAsc(orders), }, } sort.Sort(ms)

这种方案好在哪里？每个比较器可以单独测试。你可以为cmpAmountDesc写单测，而不需要构造整个排序场景。它还让排序规则的增删变得非常直观——加一个规则，往cmps里塞一个函数就行。

但每次都要自己构造MultiSorter仍然繁琐，而且len、swap要从具体类型提取，代码还是有些重复。更好的方式是泛型化，把骨架固定下来。

3.3 思路三：泛型 + 链式调用，写在项目里最舒服的版本

Go 1.18 之后有了泛型，终于可以把上面这套骨架包装得无比丝滑。先封装一个Sorter[T]：

type Sorter[T any] struct { data []T cmps []CmpFunc[T] } type CmpFunc[T any] func(a, b T) int func NewSorter[T any](data []T) *Sorter[T] { return &Sorter[T]{data: data} } func (s *Sorter[T]) Then(fn CmpFunc[T]) *Sorter[T] { s.cmps = append(s.cmps, fn) return s } func (s *Sorter[T]) Len() int { return len(s.data) } func (s *Sorter[T]) Swap(i, j int) { s.data[i], s.data[j] = s.data[j], s.data[i] } func (s *Sorter[T]) Less(i, j int) bool { a, b := s.data[i], s.data[j] for _, cmp := range s.cmps { if r := cmp(a, b); r != 0 { return r < 0 } } return false } func (s *Sorter[T]) Sort() { sort.Sort(s) }

使用时：

NewSorter(orders). Then(func(a, b Order) int { return cmpInt(a.Status, b.Status) }). Then(func(a, b Order) int { return cmpFloat64Desc(a.Amount, b.Amount) }). Then(func(a, b Order) int { return cmpTimeAsc(a.CreatedAt, b.CreatedAt) }). Sort()

需要配套一些通用的“比较原语”：

func cmpInt(a, b int) int { if a < b { return -1 } if a > b { return 1 } return 0 } func cmpFloat64Desc(a, b float64) int { if a > b { return -1 } if a < b { return 1 } return 0 } func cmpTimeAsc(a, b time.Time) int { if a.Before(b) { return -1 } if a.After(b) { return 1 } return 0 }

这样写清晰、可复用、易测试，而且链式调用读起来就像声明式排序规则，团队协作时别人看调用代码就能明白排序优先级。

现在很多项目里我会优先用这个方案，不完全是因为“高级”，而是它把业务逻辑和算法结构彻底分开，后续想加一个排序维度，不用碰排序算法那一层。

4. 稳定排序：多级排序最容易忽略的“地基”

4.1 为什么 sort.Sort 的结果会“闪跳”

接着说一个我在线 BUG 排查中遇到的真实问题。当时一个列表是双层排序：先按用户等级降序，再按注册时间降序。理论上，如果两个用户等级相同，就应该按注册时间排。但我们当时没有写注册时间的比较逻辑，等于说等级相同的用户顺序是“随机的”。

当时的现象是：接口每次返回的数据顺序都不一样，有时候用户 A 在 B 前面，刷新一下 B 又跑到 A 前面了。原因很简单——sort.Sort不是一个稳定排序算法，它不保证相等元素的原始顺序。

Go 里有一个专门的稳定排序sort.Stable，它用的是归并排序，会尽量保持相等元素的原始顺序。但注意，这里的“原始顺序”是多级排序中的陷阱：如果主排序字段相同的元素，你想保留的“原始顺序”是次要字段的有序状态，那必须让这个状态在排序前就已经存在。

4.2 稳定排序的正确姿势：先排次级字段，再排主级字段

假设我们要实现“状态升序、金额降序”。稳定排序的做法是这样的：

sort.Stable(OrderSlice, byAmountDesc) // 先按金额降序 sort.Stable(OrderSlice, byStatusAsc) // 再按状态升序

这种做法背后的原理是：稳定排序保证“相等”的元素保持之前的样子。第一轮按金额排好序后，所有金额有序。第二轮按状态排序时，如果状态相同，归并排序不会去动它们的相对位置，于是金额的顺序被保留下来了——相当于自动实现了次级排序。

用代码说就是：

type byAmountDesc []Order func (s byAmountDesc) Len() int { return len(s) } func (s byAmountDesc) Less(i, j int) bool { return s[i].Amount > s[j].Amount } func (s byAmountDesc) Swap(i, j int) { s[i], s[j] = s[j], s[i] } type byStatusAsc []Order func (s byStatusAsc) Len() int { return len(s) } func (s byStatusAsc) Less(i, j int) bool { return s[i].Status < s[j].Status } func (s byStatusAsc) Swap(i, j int) { s[i], s[j] = s[j], s[i] }

执行顺序很重要：

sort.Stable(byAmountDesc(orders)) sort.Stable(byStatusAsc(orders))

几次实际操作后，我的体会是：稳定的多级排序实现上，少写一个字段的比较逻辑，而是反着实现——先排最不重要的字段，最后排最重要的字段。这个方法在很多语言中都适用，但 Go 程序员反而容易忽略，因为 Go 的sort.Sort默认不稳定，很多人没养成用sort.Stable的习惯。

4.3 什么时候用稳定排序，什么时候不用

稳定排序是好东西，但它不是万能的。sort.Stable的时间复杂度在最坏情况下比sort.Sort差一些，空间复杂度也更差。对于业务数据几十万条以内的排序，几乎感觉不到差别，随便用；但对于上千万的数据量，可能就需要评估一下了。

另一个极端是：如果你在Less里已经写全了所有的比较字段，也就是说任何两个“不等价”的元素你都能定出前后，那稳定不稳定对你来说没有区别——因为压根就没有“相等元素”需要保序。这也是我在写基础排序规则时用的策略：兜底字段一定要写，通常用一个唯一 ID 兜底，彻底杜绝随机顺序。这样即使未来有人改了排序规则，也不会发生顺序忽变的问题。

5. 升降序混排、空值处理、浮点数比较——容易被坑的三个细节

5.1 升序降序混排不要用取反

按金额升序是a.Amount < b.Amount，直观的降序写法是a.Amount > b.Amount。但有些偷懒的写法是!cmp(a, b)，这个是大忌。

!cmp(a,b)的逻辑等价于“a 不小于 b”，意味着a == b时也会返回 true。这破坏了 Less 的严格弱序性质，排序结果会错，严重时还会导致交换逻辑陷入死循环。

正确做法是写清楚比较关系：

• 升序：a < b
• 降序：a > b

5.2 空值、零值一定要有明确的排序规则

业务里经常遇到字段为空的情况。比如订单可选优惠券、部分商品没有折扣价。如果你不给空值定义一个明确位置，那么排序结果会因为字段比较的不完整而随机化。这种事在测试里很难发现，因为测试数据一般都完整；上线后用户数据就露馅了。

我的做法是：空值统一排在后面。判断先做空值处理，再做人比较：

func cmpNullableString(a, b string, desc bool) int { aEmpty := a == "" bEmpty := b == "" if aEmpty && bEmpty { return 0 } if aEmpty { return 1 } // a 是空，排后面 if bEmpty { return -1 } // b 是空，排后面 if a < b { return -1 } if a > b { return 1 } return 0 }

注意即使排序方向是降序，空值逻辑也应该单独处理，不要因为整体降序就让空值跑到最前面。

5.3 浮点数比较：==要慎用，但排序里没有关系

很多新手在Less里写浮点数比较时，都习惯用==判断相等，然后就开始纠结浮点精度问题：“0.1+0.2 != 0.3 怎么办？”但在排序场景里，这个担忧是多余的。

排序比较只需要一个全序关系，浮点数的直接比较就是全序关系。a.Amount > b.Amount告诉你某个值是否排在另一个前面，不需要你去判断两个浮点数“在数学上是否相等”。你不需要纠结“相差 0.0000001 算不算相等”的哲学问题，因为排序要求的是：两个值必须能分出前后，或者等价。Go 的>、<本身就是严格的、确定性的比较，用它们做排序完全没问题。

唯一要注意的是NaN的存在。如果字段里可能出现 NaN，它跟任何数比都是 false，这会导致排序不稳定。你要么提前清洗数据，要么在比较函数里显式处理 NaN。

5.4 通用比较原语参考表

6. sort.Slice 能替代 Interface 吗？说说我的选型标准

现在很多人写 Go 都用sort.Slice，一句话就把 Less 写完了，比如：

sort.Slice(orders, func(i, j int) bool { if orders[i].Status != orders[j].Status { return orders[i].Status < orders[j].Status } return orders[i].Amount > orders[j].Amount })

这代码简单、直观，对于一次性排序需求完全够用。那sort.Interface的价值在哪？我分享一下自己的选型标准。

用sort.Slice的场景：

• 排序逻辑只用一次，不需要复用。
• 代码量少，局部看能得到很清晰的理解。
• 项目的 Go 版本较低，或者团队风格就是偏好函数式写法。

用sort.Interface或者自封装排序器的场景：

• 排序规则会在多个地方复用，避免复制粘贴后改漏一处。
• 需要仔细测试排序逻辑，希望每个级别单独测。
• 排序规则是动态的，依赖外部配置或参数。
• 想在排序前后加埋点、日志、统计，集中在Swap里做反而更省事。

有个实际体验：有次我们需要根据用户所在地不同的排序规则动态生成组合，比如 A 地区按“价格优先”，B 地区按“时间优先”。用sort.Slice写了一个巨大的闭包，看起来头都大了。后来改成封装一个MultiSorter，每个地区只需要配置自己的cmps列表，规则一目了然。

另外提醒一下，sort.Slice的实现本质上仍然是把闭包包装成Interface，它并没有在性能上比特地手写 Interface 有额外优势。它们都经过sort.Sort或sort.Stable的快路径，性能几乎没差别。

7. 实战：真实项目中如何落地一套可扩展的排序层

7.1 定义排序方向的枚举和可配置结构

实际项目中，排序规则往往不是写死在代码里的，而是来自 API 请求参数。客户端传来“status,asc;amount,desc;created_at,desc”这样的规则，后端要能解析并动态构造成排序器。

我建议设计一个排序配置结构体：

type SortField struct { Field string Desc bool } type SortConfig []SortField

排序器和具体结构体解耦之后，配置驱动就很自然了：

func BuildOrderSorter(data []Order) *Sorter[Order] { s := NewSorter(data) for _, field := range config.SortConfig { // config 来自请求或配置中心 switch field.Field { case "status": s.Then(cmpIntByFieldStatus(field.Desc)) case "amount": s.Then(cmpFloatByFieldAmount(field.Desc)) case "created_at": s.Then(cmpTimeByFieldCreatedAt(field.Desc)) default: continue } } s.Then(cmpIntByFieldID(false)) // 防止排序规则不足导致随机顺序 return s }

这里兜底字段的重要性再次体现：用户传了一个很随意的排序规则，哪怕只指定了一个字段，ID 兜底也能保证顺序稳定。

7.2 结合 context 实现可取消的排序

排序本身很快，但如果数据量极大（比如百万级），我们希望排序过程能响应 context 取消信号，避免占用资源。不过 Go 标准库的sort.Sort不感知 context，你只能在排序前判断一次。如果真的要持续响应取消信号，需要自己实现带取消检查的排序算法，这比较罕见，一般不建议你这么做。

对于绝大多数业务场景，排序就是毫秒级或者几十毫秒级，不需要打断。真的遇到超大集合，更应该考虑的是：是不是可以把排序下推到数据库？毕竟数据库的索引排序更划算，不要等数据加载到内存再排序。

7.3 排序性能调优实测记录

我对三种实现做过一个不怎么严谨的基准测试，数据量 10 万条 Order：

结论是：泛型封装的 MultiSorter 不会带来明显性能损失，可以放心在日常项目中使用。如果数据规模不大（几千条），这三种方案根本没有肉眼可见的差别。真正影响性能的不是排序方案，而是Less里的字段访问和数据分配。比如在比较函数中反复做字符串拼接、上级函数调用、取指针等操作，都会拖慢排序速度。

7.4 自定义数据结构的排序特殊场景

sort.Interface不止适用于结构体切片。它的Len、Less、Swap可以映射到任意数据结构上。

比如链表排序。标准库的sort.Sort要求随机访问，链表不满足，但你可以实现一个适配器：

type ListSorter struct { list *LinkedList } func (s *ListSorter) Len() int { return s.list.Len() } func (s *ListSorter) Less(i, j int) bool { a, _ := s.list.Get(i) b, _ := s.list.Get(j) return a.(int) < b.(int) } func (s *ListSorter) Swap(i, j int) { a, _ := s.list.Get(i) b, _ := s.list.Get(j) s.list.Set(i, b) s.list.Set(j, a) }

不过这依然是 O(n^2) 的获取和赋值，不如直接转切片排序再重建链表。这里只是说明Interface的抽象能力，它不关心你的底层容器是什么，只要你能实现三个方法就行。

7.5 多字段排序与索引排序的取舍

最后说一个设计层面的问题。如果数据经常需要按多种不同的字段组合排序，你会面临一个选择：在内存里每次动态排序，还是在维护数据时就按多个索引维护顺序？前者灵活但每次 O(n log n)；后者高效但实现复杂。

我的建议是：业务量在几十万条以内，直接内存排序就好；百万级以上且排序频繁、实时性要求高，就要考虑数据库层面的多字段索引，或引入专门的搜索引擎。不要用 Go 程序硬扛大规模全量排序，这不合理。如果你发现排序成了系统瓶颈，先想想有没有办法减少数据量，或者能不能把排序下推，而不是一味优化Less函数。

8. 踩坑实录：我见过的 sort.Interface 五大经典问题

结合我自己和其他同事的实际经历，整理几个典型的坑，你对照着排查肯定能少走弯路。

8.1 Less 返回规则自相矛盾

有人会把Less这么写：

func (s Orders) Less(i, j int) bool { if s[i].Status != s[j].Status { return s[i].Status < s[j].Status } if s[i].Amount != s[j].Amount { return s[i].Amount > s[j].Amount } return true // 错误！ }

当两个元素所有字段都相等时，返回 true，破坏严格弱序。排序可能在数据量大时出现异常，或者结果不稳定。

正确法则：完全相等的元素，Less 必须返回 false。

8.2 忘了处理相等，导致后续字段不生效

最常见的问题：

func (s Orders) Less(i, j int) bool { if s[i].Status != s[j].Status { return s[i].Status < s[j].Status } // 这里直接返回了？后面的字段比较永远走不到 return s[i].Amount < s[j].Amount }

这种写法其实是对的。但有另一种错法：

if s[i].Status != s[j].Status { return s[i].Status < s[j].Status } else { return false // 这里 else 分支提前结束了比较 }

一旦状态字段相等，后面字段根本没机会参与排序。排查技巧：如果你发现排序结果只对第一个字段有效，多半就是 Less 的逻辑提前返回了。

8.3 Swap 写错了位置，导致数据被覆盖

func (s Orders) Swap(i, j int) { s[i] = s[j] // 错误：直接覆盖 }

正确写法是同时赋值：

func (s Orders) Swap(i, j int) { s[i], s[j] = s[j], s[i] }

这个看起来太基础了，但我真见过有人把Swap当成“把数据搬过去”而不是“交换”。这种错误通常不会报错，只是排序结果完全不对，排查半天。

8.4 Len 返回常量，排序不完整

func (s Orders) Len() int { return 10 // 错误：写死了 }

这个错误极少发生在业务代码中，但一些自动生成的代码或者带有缓存的实现中可能出现。检查技巧：排序后如果发现数据只排了一部分，先看 Len 是不是真实的集合长度。

8.5 指针切片和值切片搞混

如果你持有的是[]*Order，实现Less时就要用s[i].Amount而不是s[i].Amount（后者根本编译不过）。这倒不是编译错误的问题，真正的问题是——如果你在Less里直接修改了指针指向的对象的值，排序过程中可能引发难以追踪的数据竞态。

比如：

func (s OrderPtrSlice) Less(i, j int) bool { if s[i].Amount == 0 { s[i].Amount = 999 // 绝对不能这么写 } return s[i].Amount > s[j].Amount }

排序算法会反复调用Less，在比较过程中副作用修改数据，会导致不可预测的结果。Less 必须是纯函数，只读不写。

9. 面试与八股之外：Go 排序真正值得深挖的点

最近 Go 面试题里很流行考排序，但很多人都在背 sort 的底层算法细节，比如“sort.Sort 什么时候用快排、什么时候用堆排、什么时候切到插入排序”。这些确实值得知道，但如果面试官深问一句“它们的切换阈值是多少”，大多数人就答不上来了。

我自己的经验是：八股记不住很正常，重要的是理解设计模型。我来帮你梳理一下 Go 的sort包内部机制：

• sort.Sort：适用于大多数情况，使用快速排序（pdqsort 变体，Go 1.19 之后切换为 pdqsort），在数据基本有序或长度小于阈值时切换到插入排序；当分区递归深度过大时切换到堆排序，保证最坏情况 O(n log n)。
• sort.Stable：使用归并排序，稳定的开销是额外的内存分配。对于已经有序或者长度很小的切片，它也会走插入排序快路径。
• sort.Slice：内部其实就是把闭包转换成Interface再交给Sort。

知道这些的好处是：你能解释清楚“为什么大多数业务排序直接用sort.Slice就够了”，同时也能解释“什么时候你自己实现Interface会更好”。面试官更看重的往往是后者——你的工程判断力。

提示：Go 1.19 之后的各种排序算法切换阈值并非常量，在不同规模的切片上表现略有不同。如果你在写底层库且追求极致性能，不要依赖于这些内部阈值，直接用sort.Sort就好。

10. 把这些经验收进工具箱

多级排序用sort.Interface实现，归根结底就是三句话：

• 在Less里按字段优先级逐个比较，能比较出结果就直接返回，不能就继续下一级。
• 要善用稳定的两次排序方案——先排次级字段，再排主级字段，能得到同样的多级效果，而且代码更简洁。
• 无论如何都要加一个唯一字段兜底，确保任何情况下排序结果都是确定性的。

我个人在实际项目里的体会是：多级排序的难点从来不是“怎么调用 sort 包”，而是“你的业务规则是否被准确地表达成了严格弱序”。写排序代码的时候，把字段的相等、空值、升降序处理想清楚，比背诵任何排序算法的细节都有价值。

如果你正被多级排序折磨，建议先把你所有的排序字段列成一个表，一行一个字段，标上优先级和升降序方向。然后从上到下把表翻译成Less代码，或者翻译成一行行Then(...)调用。这块表写清楚了，代码基本不会错。最后别忘了一个好东西：给排序逻辑写测试，把每个字段单独出测试用例，特别是“字段值相等”的情况——这是最容易出错、又最容易被漏掉的地方。

最后再分享一个小技巧，我在团队里一直提倡：排序规则涉及业务语义时，不要直接在Less里写裸的比较符号，而是给比较逻辑起一个有意义的名字，比如isHigherPriority、shouldComeBefore。这样过了一个月再回头改代码，你不需要重新揣摩那几行if想表达什么，直接看方法名就明白了。这个习惯帮我省了数不清的排查时间。