slices.SortFunc 比较函数写错会出现什么结果

slices.SortFunc 的比较函数写错后，最常见的结果不是固定 panic，而是排序结果不再具备可依赖的业务语义：切片可能看起来大致有序，却在特定值、特定输入顺序或边界数据上错序；被判为“相等”的元素还可能改变相对位置。SortFunc 会原地修改切片，但不会先验证比较器是否满足严格弱序。

生产环境里不要把 cmp 当成“随便返回正负数的回调”。它必须对同一批对象给出一致、可传递的顺序：a 在 b 前返回负数，a 在 b 后返回正数，相等或按该顺序不可比时返回 0。最稳妥的做法是用 cmp.Compare 或 strings.Compare 逐字段比较，明确相等语义，并用性质测试覆盖极值、重复值和 NaN。

SortFunc 真正依赖的是严格弱序

官方文档要求 cmp 实现严格弱序。落到代码审查，可以用四条规则理解：

• 自己与自己比较必须返回 0。
• 如果 a 在 b 前，那么 b 在 a 后，符号必须相反。
• 如果 a 在 b 前、b 在 c 前，那么 a 必须在 c 前。
• 返回 0 的对象形成一致的等价组，不能一会儿相等、一会儿又被第三个值拆开。

items := []Item{
    {ID: 3, Score: 90},
    {ID: 1, Score: 70},
    {ID: 2, Score: 90},
}

slices.SortFunc(items, func(a, b Item) int {
    // 主键按分数从高到低排列，交换参数比对结果即可
    if n := cmp.Compare(b.Score, a.Score); n != 0 {
        return n
    }
    // 分数相同时按 ID 升序，得到确定的总顺序
    return cmp.Compare(a.ID, b.ID)
})

这里的次级键不是装饰。如果业务要求每次都得到同一顺序，而主键可能重复，就要提供确定的次级键；否则返回 0 在数学上可以合法，但 SortFunc 不保证稳定，相等元素的原顺序不能作为契约。

三类常见错误和安全替代

错误一：用减法直接当返回值

写成 return int(a.ID - b.ID) 很短，却可能在整数极值或类型转换时溢出。溢出会翻转符号，让本应更小的值被判断为更大。用 cmp.Compare 返回规范的 -1、0、1，不依赖差值大小。

// 危险：差值和 int 转换都可能破坏预期符号
bad := func(a, b Record) int {
    return int(a.ID - b.ID)
}

// 安全：只表达大小关系，不计算可能溢出的差值
good := func(a, b Record) int {
    return cmp.Compare(a.ID, b.ID)
}

错误二：把“小于等于”也返回负数

如果 a 和 b 相等时仍返回负数，那么 cmp(a, a) 就不是 0，同一元素被判断为在自己之前。排序算法基于这个矛盾关系移动元素，结果可能局部错序，也无法通过同一个业务顺序解释。

wrong := func(a, b Item) int {
    if a.Score 

错误三：比较时读取会变化的外部状态

比较器如果依赖随机数、当前时间、会被其他 goroutine 修改的 map，或在回调里自增权重，同一对元素在不同调用中可能得到不同答案。SortFunc 可能多次、以不同组合调用 cmp；比较结果必须只依赖稳定输入。

func SortByCurrentRank(items []Item, rank map[int64]int) {
    // 排序前复制快照，避免比较期间读取变化中的共享 map
    snapshot := maps.Clone(rank)

    slices.SortFunc(items, func(a, b Item) int {
        if n := cmp.Compare(snapshot[a.ID], snapshot[b.ID]); n != 0 {
            return n
        }
        // 次级键消除相同排名下的不确定顺序
        return cmp.Compare(a.ID, b.ID)
    })
}

相等元素乱序不一定是比较器错误

SortFunc 明确不保证稳定。若 cmp 对两个对象返回 0，排序后它们可以互换位置。以下两种需求要分开：

slices.SortStableFunc(items, func(a, b Item) int {
    // 只比较分组键；相同分数保持输入中的相对顺序
    return cmp.Compare(b.Score, a.Score)
})

稳定排序只解决“比较器返回 0 时保留原顺序”，不能修复不传递、符号矛盾或依赖可变状态的比较器。换成 SortStableFunc 不是错误 cmp 的补丁。

浮点数与 NaN 是隐蔽边界

自己写 if a 、if a > b，然后其余情况返回 0，遇到 NaN 时容易把 NaN 与所有普通数都判成等价。这种“等价”无法保持传递：NaN 可同时与 1、2 返回 0，但 1 和 2 又不相等。标准库 cmp.Compare 对浮点数定义了完整顺序：NaN 位于非 NaN 之前，NaN 与 NaN 相等。

slices.SortFunc(metrics, func(a, b Metric) int {
    // cmp.Compare 已定义 NaN 顺序，避免手写比较造成等价关系矛盾
    if n := cmp.Compare(a.Value, b.Value); n != 0 {
        return n
    }
    return cmp.Compare(a.Name, b.Name) // 同值时用名称确定顺序
})

用性质测试审计比较器

只拿三条正常数据看输出，通常发现不了极值、重复值和三元素传递性问题。比较器应作为独立函数测试。除了排序后的示例断言，还应检查自比较、反向符号和传递性。

func sign(n int) int {
    if n  0 {
        return 1
    }
    return 0
}

func checkComparator(t *testing.T, values []Item, compare func(Item, Item) int) {
    t.Helper()

    for _, a := range values {
        if compare(a, a) != 0 {
            t.Fatalf("自比较必须返回 0: %+v", a)
        }
        for _, b := range values {
            // 反向比较的符号必须相反
            if sign(compare(a, b)) != -sign(compare(b, a)) {
                t.Fatalf("反向符号不一致: a=%+v b=%+v", a, b)
            }
            for _, c := range values {
                // a= 0 {
                    t.Fatalf("传递性失败: a=%+v b=%+v c=%+v", a, b, c)
                }
            }
        }
    }
}

slices.IsSortedFunc 可以检查排序后的切片是否符合当前 cmp，但它仍使用同一个比较器，无法证明比较器符合真实业务意图，也不能替代严格弱序性质测试。发布检查应同时保留业务样例断言与性质测试。

上线前检查清单

• 相等元素是否明确返回 0。
• 是否避免用整数减法表达大小关系。
• 比较器是否只读取不可变输入或排序前快照。
• 多字段排序是否在主键相等时继续比较次级键。
• 需要保留原顺序时是否使用 SortStableFunc。
• 浮点字段是否使用 cmp.Compare 处理 NaN。
• 测试数据是否包含重复值、零值、极值、NaN 和不同输入排列。

常见问题

比较器写错一定会 panic 吗？ 不一定。比较器自身 panic 会向外传播，但违反严格弱序更常见的表现是结果错序或不稳定，不能依赖某一种固定故障形式。

返回 -100 或 100 可以吗？ 可以，SortFunc 只关心符号；但直接用差值容易溢出，推荐返回 cmp.Compare 的 -1、0、1。

排序结果每次一样就说明 cmp 正确吗？ 不能。当前数据可能没有触发矛盾组合，算法实现也可能暂时产生相同结果；仍需验证严格弱序和业务期望。

参考资料：https://pkg.go.dev/slices#SortFunc；https://pkg.go.dev/slices#SortStableFunc；https://pkg.go.dev/cmp#Compare