Go sort.Slice比较器不满足严格弱序时的异常表现

用 sort.Slice 排序时，如果 less(i, j) 没有表达稳定的严格弱序，最常见的结果不是立即报错，而是同一批数据在不同输入顺序下得到不同排列，甚至出现看起来“没有排好”的元素。修复重点不在换一个排序函数，而在让比较器满足自反性、传递性和等价关系的一致性。

官方地址：https://pkg.go.dev/sort

异常表现通常来自比较关系自相矛盾

sort.Slice 只知道一个切片和一个 less 函数，并不会替应用检查所有元素之间的关系。比如比较器把“状态相同”当成相等，却又在下一次调用里读取会变化的时间或全局计数器；排序过程中同一对元素的答案就可能改变。更隐蔽的情况是三元组出现 A

下面这个错误写法把“任意不相等”都当成前者更小，它连自身比较都返回真：

package main

import "sort"

type Task struct {
    Priority int
    Name     string
}

func badSort(tasks []Task) {
    sort.Slice(tasks, func(i, j int) bool {
        // 错误：不相等才返回 true，less(i, i) 也会变成 true。
        return tasks[i].Priority != tasks[j].Priority
    })
}

它可能在小数据上“碰巧有序”，但这不是可依赖的结果。判断问题时先固定输入副本，打印比较器的三元组结果，而不是先怀疑 sort 包。

多字段比较要让键优先级显式化

业务排序常见写法是先按优先级，再按名称，最后按编号。正确做法是每层只在两个值不相等时返回结论；所有键都相等时返回 false。这样 A 与 B 的关系不会因为后续分支重新推翻前面的判断。

sort.Slice(tasks, func(i, j int) bool {
    left, right := tasks[i], tasks[j]
    // 先比较高优先级字段，方向要在这里一次确定。
    if left.Priority != right.Priority {
        return left.Priority > right.Priority
    }
    // 主键相等时再用名称消除部分并列。
    if left.Name != right.Name {
        return left.Name 

如果还要按编号排序，就把编号作为最后一个确定性键。不要在比较器里调用会修改对象的方法，也不要读取会随调用变化的全局状态。浮点字段还要单独处理 NaN，因为普通的“小于”判断无法自然地把 NaN 排进一个完整、可解释的序列。

需要保留并列项顺序时再选择稳定排序

严格弱序只要求比较关系一致，不承诺等价元素保持输入顺序。比如只按 Priority 排序时，优先级相同的任务属于等价元素。如果产品要求它们继续遵循进入队列的顺序，应改用 sort.SliceStable：

sort.SliceStable(tasks, func(i, j int) bool {
    // 只比较业务优先级；相同优先级保留原有相对顺序。
    return tasks[i].Priority > tasks[j].Priority
})

若需求是“同优先级也必须完全确定”，则继续补充创建时间、序号或唯一 ID，并在文档中写清升降序。稳定排序和完整 tie-breaker 是两种不同需求，不能用其中一个替代另一个。

用三元组测试比较器，而不是只测最终数组

最终数组正确只能说明这一次输入通过。更可靠的测试覆盖四个检查：任意 x 都满足 less(x,x)==false；若 A

把这些断言放进排序器的单元测试，后续新增字段时就能在评审阶段发现关系被破坏，而不是等线上列表偶发跳动才追查。

常见问题

比较器不满足严格弱序，sort.Slice 会直接 panic 吗？

不能把 panic 当成必然现象。比较器不一致时更常见的是结果不可预测；是否触发越界或 panic 取决于具体实现和输入，应用应修复比较器契约而不是依赖异常。

多个字段都相等时应该返回什么？

返回 false。这表示两个元素在当前排序键下等价；需要固定次序就追加确定性键，要求保留原顺序则使用稳定排序。

为什么小切片正常，大切片却暴露问题？

小输入只触发比较关系的一部分，未必覆盖矛盾的三元组。数据量增大或输入顺序变化后，算法会访问更多元素对，隐藏的比较器问题就会显现。