sort SliceStable 何时值得替代 Slice

如果排序键相等的记录还要保持输入顺序，sort.SliceStable 才值得替代 sort.Slice。如果相等记录的先后没有业务含义，普通的 sort.Slice 通常更直接；不要因为“稳定”听起来更安全，就在所有列表上无条件使用它。

两者都会原地修改传入的切片，也都要求 less 函数满足与 sort.Interface.Less 相同的排序规则。核心区别只有一个：sort.Slice 不保证相等元素的原始顺序，sort.SliceStable 会保留这个顺序。下面按排查清单把选择、风险和成本拆开。

先看相等记录是不是业务顺序

把排序函数放进代码前，先问一句：当两个元素在 less 看来相等时，它们的原始先后是否仍然代表信息？

这里的“相等”只指比较函数认为两项互不先于对方：less(i, j) 和 less(j, i) 都为 false。它不要求两个结构体的所有字段都一样。比如两条订单的优先级相同，但订单号不同，仍然可能是稳定性需要保护的相等组。

用同一组记录检查不稳定排序的风险

下面故意让 Score 相同的记录带有不同的输入顺序。这个例子不依赖某一次运行恰好输出什么，而是把 API 保证写成代码旁的判断：普通排序不能承诺相等项仍按输入顺序排列。

package main

import (
    "fmt"
    "sort"
)

type Result struct {
    Name  string
    Score int
}

func main() {
    results := []Result{
        {Name: "甲", Score: 80},
        {Name: "乙", Score: 90},
        {Name: "丙", Score: 80},
    }

    // Slice 只按 Score 排序；Score 相等时不承诺 Name 的输入顺序。
    sort.Slice(results, func(i, j int) bool {
        return results[i].Score 

两个函数的输入都必须是切片，否则会触发 panic；比较函数也都不能用“偶尔成立”的条件拼凑出顺序。实际项目里，最容易误判的是：某次测试中 sort.Slice 恰好没有交换相等元素，于是测试把偶然结果固化成断言。只要顺序有业务含义，就直接选稳定排序或增加明确的第二排序键。

多关键字排序要从次要键开始

稳定排序最有价值的地方，是把多个简单排序组合成可读的步骤。假设报表要先按 Priority 升序，再在同一优先级内按输入时的 CreatedAt 顺序排列，应该先按次要键 CreatedAt 排序，再用 SliceStable 按主要键 Priority 排序。

type Task struct {
    ID        string
    CreatedAt int64
    Priority  int
}

func orderTasks(tasks []Task) {
    // 第一步处理次要键；它会成为主要键相等组内的保留顺序。
    sort.SliceStable(tasks, func(i, j int) bool {
        return tasks[i].CreatedAt 

如果把第二步换成 sort.Slice，同优先级任务的时间顺序就没有 API 保证；如果把两步顺序反过来，最终含义也会改变。更简单的替代方式是一次比较多个字段，但那已经是“显式补充排序键”的方案，不是本文要讨论的多次稳定排序。

成本怎么判断：不要用“稳定一定更慢”代替基准

SliceStable 提供了额外的顺序保证，通常意味着实现需要为稳定性付出更多移动或比较工作；但一次排序的真实耗时还会受到元素大小、比较函数成本、数据是否接近有序和分配情况影响。因此，“稳定排序一定慢多少”没有一个可以套用到所有项目的固定答案。

可以按下面的检查顺序做取舍：

1. 先确认语义：相等键的原始顺序若是结果的一部分，性能优化不能删掉稳定性。
2. 再确认数据：小切片、低频后台任务通常不值得为了几次比较改写业务逻辑。
3. 再测关键路径：用代表性数据覆盖随机、近乎有序和大量相等键三种形态。
4. 最后看替代方案：如果可以安全地增加唯一的第二键，一次比较多字段有时比多次稳定排序更合适。

func BenchmarkSortChoice(b *testing.B) {
    base := makeTasks(10000)
    b.Run("unstable", func(b *testing.B) {
        for b.Next() {
            tasks := append([]Task(nil), base...)
            // 每次复制输入，避免上一次排序改变下一次基线。
            sort.Slice(tasks, func(i, j int) bool {
                return tasks[i].Priority 

基准只负责回答“这组数据在这台机器上怎样”，不负责证明稳定性可有可无。若延迟预算很紧，建议同时记录比较函数是否包含字符串比较、切片复制是否计入测量，以及结果是否需要稳定顺序。

发布前的反向检查清单

• 比较关系：less 表示严格弱序，不能同时出现互相矛盾的结果。
• 稳定语义：只有在排序键相等时，SliceStable 才承诺保持原始相对顺序；它不会替你定义第二个键。
• 输入副作用：两个函数都原地重排切片；需要保留原始输入时，先复制切片。
• 类型边界：传入的值必须是切片，不能把数组、结构体或 nil 接口误当成可排序集合。
• 验证方式：不要只断言“已按主键升序”，还要在相等键组内断言业务要求的顺序。

结论：稳定性是语义选择，不是默认升级

可以把判断压缩成一句话：相等元素的输入顺序有意义，就用 sort.SliceStable；没有意义，就用 sort.Slice，并在关键路径上用代表性数据做基准。需要多关键字排序时，稳定排序应从次要键开始，再按主要键收敛结果。

相关问题

sort.SliceStable 会复制原切片吗？

不会。它和 sort.Slice 一样直接重排传入的切片元素；调用前需要复制时，应由业务代码明确完成。

相等元素是指结构体完全相同吗？

不是。只要比较函数没有判定其中一项排在另一项之前，它们在本次排序里就是相等组，即使其他字段不同。

能不能只调用一次 SliceStable 完成多关键字排序？

可以把多个字段写进一个比较函数；此时要明确主键和次键的优先级。多次稳定排序则适合把每个关键字拆成独立步骤，且必须先排次要键。