Go sort.SliceStable 与 slices.SortStableFunc 怎么选

在 Go 里做稳定排序，结论可以先说清楚：项目已经使用 Go 1.21 或更高版本时，新代码通常优先选择 slices.SortStableFunc；只有需要兼容更早的 Go 版本，或者现有比较逻辑强依赖切片索引时，才更适合继续使用 sort.SliceStable。两者都会原地修改切片，也都会让比较器判定为“相等”的元素保持原来的相对顺序。

触发信号：什么时候需要重新选择稳定排序 API

常见触发点有三个：项目升级到了 Go 1.21 以上，代码审查发现大量 any 和索引闭包，或者线上结果里同一业务键的记录顺序发生了变化。前两种情况偏向可维护性改造，后一种则通常意味着比较器把本应相等的元素继续比较了次级字段，或者误用了非稳定排序。

Go 官方文档对两种函数的稳定性描述一致：相等元素保持原来的相对顺序。差别主要在比较器入口。sort.SliceStable 接收任意切片和 less(i, j) bool，比较器通过索引回到原切片取值；slices.SortStableFunc 是泛型函数，接收具体元素值和 cmp(a, b) int。标准库的 slices 包从 Go 1.21 开始提供。

快速判断：四种场景怎么选

官方 sort 文档也提示，较新的 slices.SortStableFunc 在许多情况下更符合人体工程学，并可能运行得更快。不过选择时不要只依赖笼统的性能判断；如果排序位于热点路径，仍应基于自己的数据规模、比较成本和 Go 版本做基准测试。

处理步骤：先看懂两种比较器契约

下面用同一组任务数据按 Group 排序。原始数据中，A 组的序号是 2、3，B 组的序号是 1、4。稳定排序后组别会聚合，但每个组内部仍保持这个原始顺序。

type Job struct {
    Group string
    Seq   int
    Name  string
}

jobs := []Job{
    {Group: "B", Seq: 1, Name: "build"},
    {Group: "A", Seq: 2, Name: "lint"},
    {Group: "A", Seq: 3, Name: "test"},
    {Group: "B", Seq: 4, Name: "deploy"},
}

使用 sort.SliceStable 时，比较器拿到的是索引。它必须闭包捕获 jobs，再通过 jobs[i] 和 jobs[j] 读取字段：

sort.SliceStable(jobs, func(i, j int) bool {
    // 只比较 Group；同组元素会保留输入时的相对顺序
    return jobs[i].Group 

这种写法兼容范围广，也适合比较逻辑确实需要位置关系的旧代码。代价是函数签名无法在编译期表达元素类型，而且比较器与被捕获的切片绑定得更紧。传入值不是切片时，sort.SliceStable 还会触发 panic。

使用 slices.SortStableFunc 时，比较器直接得到两个 Job 值，并用负数、零、正数表示小于、等于、大于：

slices.SortStableFunc(jobs, func(a, b Job) int {
    // cmp.Compare 返回负数、0 或正数；0 表示交给稳定性保留原顺序
    return cmp.Compare(a.Group, b.Group)
})

这里不再需要通过索引回到切片取值。对于普通结构体切片，新写法更容易单独测试比较器，也更不容易在重命名变量或调整切片来源时误捕获另一个切片。

迁移时先守住“相等”语义

稳定性只对比较器认定为相等的元素生效。按 Group 排序时，同组记录必须返回 0，原始先后顺序才会被保留。如果又比较 Seq，那么同组但不同序号的元素已经不再相等，最终顺序由 Seq 决定，而不是由稳定性决定。

slices.SortStableFunc(jobs, func(a, b Job) int {
    if byGroup := cmp.Compare(a.Group, b.Group); byGroup != 0 {
        return byGroup // 组别不同，先按 Group 排序
    }
    return cmp.Compare(a.Seq, b.Seq) // 加入 Seq 后，同组元素不再都相等
})

这段代码本身没有错，但它表达的是“Group 升序，再按 Seq 升序”，而不是“仅按 Group 聚合并保留原顺序”。迁移前应先把业务规则写成一句话，再决定相等分支返回 0 还是继续比较。整数比较也不要写成 a.Seq - b.Seq，因为极端值可能溢出；使用 cmp.Compare 更清晰。

回滚路径：不要一次改掉比较器和业务规则

1. 先保留原有 sort.SliceStable 版本，记录它只比较了哪些字段。
2. 把同一字段规则平移为 cmp(a, b) int，相等分支明确返回 0。
3. 不要在同一个提交里顺便添加次级排序、改变升降序或调整数据预处理。
4. 若结果断言不一致，先恢复旧调用，再逐项比较两套比较器对同一元素对的判断。

两种函数都会原地重排切片。如果调用方还要保留原始顺序，应在排序前复制切片，而不是把“稳定排序”误解成“不改变输入”。

sortedJobs := slices.Clone(jobs) // 复制切片，保留调用方的原始顺序
slices.SortStableFunc(sortedJobs, func(a, b Job) int {
    return cmp.Compare(a.Group, b.Group) // 只按 Group 稳定排序副本
})

告警确认：用原始序号验证稳定性

上线前至少保留一个包含重复键的测试。不要只检查 A 是否排在 B 前面，还要检查 A 组与 B 组内部的原序号。对于上面的样例，预期顺序应是 A2、A3、B1、B4。

wantSeq := []int{2, 3, 1, 4}
for i, want := range wantSeq {
    if jobs[i].Seq != want {
        // 同键元素顺序变化时立即失败，避免只验证主键排序
        t.Fatalf("位置 %d: got Seq=%d, want Seq=%d", i, jobs[i].Seq, want)
    }
}

如果比较器会读取可变状态、当前时间或在比较过程中修改元素，排序关系可能不一致。无论使用哪个 API，都应让比较器保持纯粹：同一对输入在整个排序期间给出一致结果。

复盘项：迁移完成后检查什么

• 版本边界：go.mod 和实际构建环境是否都支持 Go 1.21 及以上。
• 相等定义：业务真正需要保序的字段组合，是否在比较器里返回 0。
• 原地修改：调用方是否错误地假设排序前切片仍可按原顺序使用。
• 索引依赖：旧比较器是否还引用了平行切片、位置权重或外部可变状态。
• 测试覆盖：是否包含重复键、空切片、单元素、已经有序和逆序数据。

相关问题

Go 1.21 之后 sort.SliceStable 就不能用了吗？

仍然可以使用，也没有因为 slices.SortStableFunc 出现而失去语义。它更适合兼容旧代码或索引型比较器；新代码则通常能从泛型类型检查和元素值比较器中获益。

slices.SortFunc 和 slices.SortStableFunc 有什么区别？

二者都使用三路比较器，但只有 SortStableFunc 承诺保留相等元素的原相对顺序。如果同键记录的输入顺序有业务意义，就要选择稳定版本。

稳定排序能代替显式次级排序吗？

不能。稳定排序保留的是输入中已有的相对顺序；如果业务要求按第二字段排序，就应在比较器里明确比较第二字段。反过来，如果只想保留原顺序，就不要添加次级字段。

小结：Go 1.21+ 的新代码优先用 slices.SortStableFunc，旧版本兼容或强索引依赖场景保留 sort.SliceStable。真正决定结果是否稳定的关键，是比较器对“相等”的定义；迁移时保持字段规则不变，并用重复键样例验证原始序号，才能避免 API 更新顺带改变业务顺序。

官方资料：sort.SliceStable、slices.SortStableFunc、Go 1.21 发布说明。