Go slices.SortFunc 排序不稳定怎么办：比较函数一致性与重复元素边界

订单列表按“紧急程度优先、创建时间倒序”展示时，slices.SortFunc 的结果偶尔和测试样例不一样，最容易被误判成排序算法不稳定。真正要先查的是比较函数：它必须对相等、反向比较和传递关系给出一致结果；如果还要求相同优先级保持原顺序，就应该换成 slices.SortStableFunc。

slices.SortFunc 只负责按照 cmp 的结果排序，不承诺等价元素的原顺序。先把“相等时返回 0”写对，再决定是否需要稳定排序。

线上列表变大后，问题从“能排序”变成了“顺序能不能解释”

小批量数据只有三五条时，比较函数写得不严谨也不一定马上暴露。订单量上来后，优先级相同的记录会被多次比较，测试里原本排在前面的订单可能换位；如果产品又把这个顺序当作用户操作依据，排查就会从 UI 一路追到 cmp。

这里先别急着换稳定排序。先明确业务到底需要哪一种结果：只要优先级分组正确，还是同组内必须按进入列表的先后保持不变。两者是不同的契约。

先把 cmp 的三种结果固定下来

Go 的新切片排序 API 使用整数比较函数。下面的 cmp 只按优先级排序，数值越小越靠前；当优先级相同，它返回 0，而不是继续凭借订单号做隐藏排序。

package main

import (
    "fmt"
    "slices"
)

type Order struct {
    ID       string
    Priority int
}

func main() {
    orders := []Order{
        {ID: "A-102", Priority: 2},
        {ID: "B-301", Priority: 1},
        {ID: "A-103", Priority: 2},
    }

    cmp := func(a, b Order) int {
        switch {
        case a.Priority  b.Priority:
            return 1
        default:
            return 0
        }
    }

    slices.SortFunc(orders, cmp)
    fmt.Println(orders)
}

这段代码的可验证结果是：B-301 一定排在两个优先级为 2 的订单前面；A-102 和 A-103 互相比较时返回 0，但它们的相对顺序不属于 slices.SortFunc 的保证。

从实现链路看，cmp 的结果交给 slices.SortFunc，再进入内部排序辅助函数 sort.order2；这张图只描述这三个真实节点之间的数据关系。

比较函数不完整时，排序结果为什么会像随机变化

最常见的错误是只写“a 比 b 小”这一半，剩下情况返回固定值。例如下面的写法在优先级相等时也返回 -1，相当于告诉排序器“a 永远应该在 b 前面”。但当排序器反过来比较 b 和 a 时，得到的结论仍然是 b 在 a 前面，关系就冲突了。

badCmp := func(a, b Order) int {
    if a.Priority 

修复思路不是给结果加一个随机种子，也不是循环多排几次，而是让同一对值满足反向一致：cmp(a, b) 为负时，cmp(b, a) 应为正；相等时两边都应为 0。还要避免比较过程中读取会变化的全局状态。

等价订单需要保留输入顺序时，改用稳定排序

如果需求是“优先级相同的订单保持数据库查询返回的先后”，那就把这个要求写进 API 选择，而不是寄希望于普通排序碰巧不换位。slices.SortStableFunc 接收相同形状的 cmp，但会保留比较结果为 0 的元素相对顺序。

slices.SortStableFunc(orders, cmp)

这不是无条件更优。稳定排序需要额外的移动或辅助空间，数据量很大、同组顺序没有业务意义时，slices.SortFunc 的约束更简单。我的判断顺序通常是：先写清等价定义，再确认同组顺序是否可见，最后才选稳定版本。

图中的分界点就是 cmp == 0：普通 slices.SortFunc 不承诺等价元素顺序，而 slices.SortStableFunc 把输入顺序保留下来。

把排序契约放进测试，而不是放在样例输出里

不要只断言整个切片等于一份固定输出，因为普通排序的等价元素顺序可能变化。更有用的测试是验证优先级单调不下降，并单独测试比较函数的反向关系。

for i := 1; i  orders[i].Priority {
        panic("priority order violated")
    }
}

if got := cmp(orders[0], orders[0]); got != 0 {
    panic("self comparison must be zero")
}

需要验证稳定性时，再用带有输入序号的重复优先级数据，调用 slices.SortStableFunc 后检查序号仍按原顺序排列。这样测试验证的是契约，而不是某次运行恰好打印出的排列。

常见问题

slices.SortFunc 会随机打乱相同元素吗？

它不承诺等价元素的相对顺序，因此同一程序版本、不同输入排列或不同实现细节下都不应依赖它保持原顺序；这不等同于随机算法。

比较函数可以返回任意负数和正数吗？

可以，调用方只关心小于 0、等于 0 和大于 0 三个区间。返回 -1、0、1 最容易读和测，但不是强制格式。

优先级相同还想按 ID 排序怎么办？

把 ID 作为明确的第二排序键，并在所有分支上返回一致结果；如果想保留原顺序，就不要偷偷加入 ID，而应使用 slices.SortStableFunc。

最后检查这三个边界

• 比较自身是否返回 0，交换参数后符号是否相反。
• 比较过程中是否读取了会变化的时间、随机数或共享状态。
• 等价元素的原顺序是否是业务要求；是就选 slices.SortStableFunc，不是就只验证排序键的顺序。

把“结果不一样”拆成“排序键错了”与“等价元素未保持顺序”两类，通常就能很快定位问题。API 没有失约，真正需要补齐的是比较函数和调用方的排序契约。