Go slices.SortFunc 怎么选比较器：等值排序、稳定性与三种排序边界

订单列表要先按金额降序，再按下单时间升序时，很多 Go 代码会在 sort.Slice、slices.SortFunc 和 slices.SortStableFunc 之间来回换。真正影响结果的不是函数名，而是比较器是否满足“负数、零、正数”的约定，以及同值记录是否必须保留原顺序。把这两个问题理清楚，排序 API 就不用靠猜怎么写。

先把订单排序需求拆成两个判断

假设订单结构如下：金额越大越靠前，金额相同则越早下单越靠前；如果金额和时间都相同，还要保留数据库返回的原始编号顺序。这里其实有两层规则：

• 第一层是字段之间的大小关系：比较器能不能稳定地告诉排序函数谁应该在前面。
• 第二层是等值记录的处理：排序函数发现两个订单“相等”后，是否还要保留它们原来的相对顺序。

第一层决定比较器怎么写，第二层决定是否需要稳定排序。不要一上来就把所有列表都换成稳定排序；稳定性有明确业务价值时再付出这份约束和成本。

三种 slices 排序 API 的选择边界

如果只是把一组商品编号从小到大排列，slices.Sort(ids) 足够清楚。结构体排序则使用函数比较器；只有当“同分时按原始顺序”本身就是页面或报表规则，才选择稳定版本。

比较器要返回三种关系，不要只返回一个布尔值

slices.SortFunc 使用的是三值比较器。以金额降序、时间升序为例，可以把规则写成一个短函数：

package main

import (
	"cmp"
	"slices"
	"time"
)

type Order struct {
	ID      string
	Amount  int64
	Created time.Time
}

func compareOrder(a, b Order) int {
	if a.Amount != b.Amount {
		return cmp.Compare(b.Amount, a.Amount) // 金额降序
	}
	return a.Created.Compare(b.Created) // 时间升序
}

func sortOrders(orders []Order) {
	slices.SortFunc(orders, compareOrder)
}

这里返回负数，表示 a 应排在 b 前面；返回零表示这两个订单在当前排序规则下等价；返回正数则相反。金额降序的关键是把参数顺序交给 cmp.Compare 时反过来，别把注释写成降序、代码却仍然是升序。

不要把旧的 sort.Slice 写法直接改成：

slices.SortFunc(orders, func(a, b Order) bool {
	return a.Amount > b.Amount
})

这段代码的返回类型不符合三值比较器契约。若项目仍在使用返回 bool 的排序函数，可以继续保留旧 API；迁移到 slices.SortFunc 时要重新表达“相等”这条关系。

同值订单要不要保留原顺序

普通 SortFunc 只关心比较器给出的排序结果。两个订单的金额和时间都相同时，比较器返回零，标准库不承诺它们仍按输入顺序排列。如果页面把数据库的 id 顺序当作最后的展示依据，就需要稳定排序：

func sortOrdersStable(orders []Order) {
	slices.SortStableFunc(orders, compareOrder)
}

稳定排序并不会替你补上第三个排序字段。若业务明确要求“金额相同再按时间相同再按 ID 升序”，应直接把 ID 放进比较器：

func compareOrderWithID(a, b Order) int {
	if n := cmp.Compare(b.Amount, a.Amount); n != 0 {
		return n
	}
	if n := a.Created.Compare(b.Created); n != 0 {
		return n
	}
	return cmp.Compare(a.ID, b.ID)
}

可以把它理解成两个不同问题：稳定排序保留“输入顺序”，第三字段排序定义“新的业务顺序”。二者不要混在一起。

用小测试锁住等值和边界结果

比较器最容易在等值分支出错，测试数据不要只放三条金额不同的订单。至少放两组完全相等的金额和时间，并明确预期 ID 顺序：

func TestSortOrdersStable(t *testing.T) {
	base := time.Date(2026, 8, 9, 10, 0, 0, 0, time.UTC)
	orders := []Order{
		{ID: "o-3", Amount: 900, Created: base},
		{ID: "o-1", Amount: 1200, Created: base},
		{ID: "o-2", Amount: 1200, Created: base},
	}

	slices.SortStableFunc(orders, compareOrder)
	want := []string{"o-1", "o-2", "o-3"}
	got := make([]string, 0, len(orders))
	for _, order := range orders {
		got = append(got, order.ID)
	}
	if !slices.Equal(got, want) {
		t.Fatalf("got %v, want %v", got, want)
	}
}

如果改用非稳定排序，这个测试可能暴露输入顺序不再是契约。生产代码应先决定这是不是要被断言的业务规则，再选 API，而不是测试失败后才临时加稳定排序。

哪些情况不适合用三值比较器硬凑

浮点数包含 NaN 时，简单的大小比较可能无法形成可靠的全序；金额最好使用整数最小单位，或者在进入排序前完成明确的缺失值处理。时间字段为空时，也要先规定空时间排前还是排后，不要让零值悄悄改变列表含义。

另外，排序会原地改变切片底层数组。如果调用方还要保留数据库原始顺序，先复制一份：

sorted := slices.Clone(orders)
slices.SortFunc(sorted, compareOrder)

这个复制动作比“排序后再想办法恢复”更容易审查。大列表要关注复制带来的内存峰值，但也别为了省一次分配，把共享切片在多个请求之间原地改掉。

提交前的选择清单

1. 基础有序类型直接使用 slices.Sort。
2. 结构体自定义字段比较使用 slices.SortFunc，比较器返回负数、零、正数。
3. 同值元素必须保留输入顺序时使用 slices.SortStableFunc。
4. 业务本来就有第三排序字段时，把它写进比较器，不要依赖稳定排序的偶然效果。
5. 调用方要保留原切片时先 slices.Clone，并给空值、等值和边界时间补测试。

常见问题

slices.SortFunc 返回零是不是代表两个结构体完全相等？

不是。它只代表两个元素在当前比较规则下没有先后关系，其他字段仍然可能不同。

稳定排序是不是任何时候都更好？

不是。稳定性只有在同值元素的输入顺序有业务意义时才值得保留；否则先用普通排序并把实际排序字段写完整。

能不能在比较器里修改订单字段？

不建议。比较器应只读输入并返回关系，修改字段会让排序关系前后不一致，排查结果也会变得很困难。

把排序选择写成可复查的规则

slices.Sort、slices.SortFunc 和 slices.SortStableFunc 并不是“新旧 API 三选一”的题目。先确定元素能否直接比较，再确定比较器的等值语义，最后判断输入顺序是否需要保留。把这三个判断和测试一起提交，后面再增加金额、时间或状态字段时，排序结果才不会靠实现细节碰运气。