Go sort 排序结果不稳定是不是比较函数不满足约束

Go 的排序结果看起来“不稳定”，首先要区分两种情况：一是 Less 没有描述严格弱序，排序关系本身不一致；二是多个元素在比较器看来相等，调用了不保证稳定顺序的 sort.Sort 或 sort.Slice。前者需要修比较函数，后者应改用 sort.Stable 或补充次关键字。

标准库的约束很具体：如果 Less(i, j) 和 Less(j, k) 都为真，那么 Less(i, k) 也必须为真；如果两段关系都表示“不小于”，第三段也不能突然变成“小于”。

先判断：是比较器失序，还是相等元素重排

所以，“结果变了”本身不是证据。先用 sort.IsSorted 检查最终序列是否仍满足当前比较器，再检查比较器是否对同一对元素返回了可重复的结果。

Less 需要满足哪些严格弱序约束

可以把 Less 当成一个关系函数，而不是“尽量返回一个看起来合理的布尔值”。它至少要满足三项检查：

1. 自反性：同一个元素不能排在自己之前，Less(i, i) 必须为假。
2. 传递性：a 且 b 时，必须有 a 。
3. 等价类一致：如果 a 与 b 互不小于，b 与 c 也互不小于，那么 a 与 c 也应互不小于。

最常见的错误是把不同业务规则拼成环。例如按“优先级升序”比较，遇到相同优先级又按时间降序，但某个分支误用了升序；或者比较函数读取了会被其他 goroutine 修改的字段。排序期间参与比较的字段应当来自稳定快照，不能一边排序一边改变。

多字段排序的修正方式

多字段比较要按优先级逐层返回：主字段不同就立刻返回主字段结果；主字段相等才比较次字段；所有字段都相等时返回假。不要在最后用随机值、当前时间或不受控的指针地址打破平局。

package main

import (
    "fmt"
    "sort"
)

type Task struct {
    Priority int
    Created  int64
    Name     string
}

func main() {
    tasks := []Task{
        {Priority: 2, Created: 30, Name: "cache"},
        {Priority: 1, Created: 20, Name: "api"},
        {Priority: 2, Created: 10, Name: "worker"},
    }

    sort.SliceStable(tasks, func(i, j int) bool {
        // 先按优先级升序；主字段不同时不再读取其他字段。
        if tasks[i].Priority != tasks[j].Priority {
            return tasks[i].Priority 

这里使用 SliceStable 是因为业务可能还有未写入比较器的隐含顺序；如果已经有明确且唯一的次关键字，普通 Slice 也可以。稳定排序只能解决“相等元素保持输入顺序”，不能修复一个不满足传递性的 Less。

浮点、动态数据和测试清单

浮点数要特别注意 NaN：因为 NaN 与任何数的普通小于比较都可能为假，直接写 x[i] 无法形成完整一致的排序关系。可以参考标准库 Float64Slice.Less 的策略，把 NaN 明确定义为排在其他值之前，或者在进入排序前把 NaN 分组处理。

排查时按下面顺序做：

1. 复制输入切片，确保比较期间不会被并发写入。
2. 对随机样本检查 Less(i, i) 是否为真，并抽查三元组的传递关系。
3. 排序后调用 sort.IsSorted；它只能确认结果符合当前比较器，不能证明比较器设计正确。
4. 主字段相等时，明确选择 sort.SliceStable，或写出确定的次关键字。

相关问题

sort.Sort 和 sort.Stable 有什么区别？ 两者都按 Less 升序排列，但 Sort 不保证相等元素的原始顺序，Stable 会保留这段顺序。

IsSorted 返回 true 就说明 Less 正确吗？ 不一定。它只是在当前数据上检查相邻关系；如果比较器存在隐藏的非传递规则或输入在比较时变化，仍需单独测试关系约束。