Go sort.SliceStable 为什么能保留相等元素原顺序

如果一组记录按同一个字段排序，而字段值相同的记录还要维持原来的先后关系，就应使用 sort.SliceStable。它的“稳定”不是让整个切片保持不变，而是只保护 less 判定为相等的元素：排序键相同的记录不会被彼此交换。

相等元素为什么需要保留原顺序

假设订单先按优先级排序，同一优先级的订单还没有单独的时间排序规则。输入中优先级为 2 的订单依次是 A、B、C，那么稳定排序后它们仍应是 A、B、C。这个顺序可能来自数据库返回、用户拖拽或上一轮排序；一旦被打乱，分页合并和界面刷新就容易出现“同条件记录跳动”。

这里的“相等”由 less 决定。两个记录互相比较时都返回 false，它们就在当前比较器下属于同一个等价组。记录的其他字段即使不同，也不影响这一判断。

sort.SliceStable 的最小写法

它接收一个切片和一个比较函数，下面只按 Priority 升序。Seq 用来观察输入顺序，但不参与比较，因此相同优先级的记录会保留原排列。

package main

import (
	"fmt"
	"sort"
)

type Task struct {
	Name     string
	Priority int
	Seq      int
}

func main() {
	tasks := []Task{
		{Name: "A", Priority: 2, Seq: 1},
		{Name: "B", Priority: 1, Seq: 2},
		{Name: "C", Priority: 2, Seq: 3},
	}

	// 比较器只表达主排序键；Priority 相等时返回 false。
	sort.SliceStable(tasks, func(i, j int) bool {
		return tasks[i].Priority 

这段写法的关键不在于“稳定排序会记住每条记录的序号”，而在于排序算法对比较器认定为相等的元素提供了顺序保证。若把 Seq 也写进比较器，顺序就由两个字段共同决定，稳定性不再承担这个业务含义。

sort.Slice 和 sort.SliceStable 怎么选

sort.Slice 不承诺相等元素的原顺序，所以不要依赖某次运行碰巧得到的排列。稳定排序也不是“更准确的排序”：它只增加了等价组内顺序的保证，通常会带来额外的交换或存储成本，数据量很大且顺序无关时没必要默认使用。

多字段排序不要把规则藏在稳定性里

如果需求是“优先级升序，优先级相同再按创建时间升序”，就把两层规则写清楚。这样无论输入来自哪里，结果都由记录本身决定：

sort.Slice(tasks, func(i, j int) bool {
	// 先比较主键；只有主键相等时才进入次键判断。
	if tasks[i].Priority != tasks[j].Priority {
		return tasks[i].Priority 

如果创建时间也相同，但业务仍要求保留数据库返回顺序，则可以改用 SliceStable，并只比较优先级和创建时间；这时稳定性就是最后一层明确的业务规则。

相关问题

相等元素是指结构体所有字段都相同吗？

不是。它只取决于 less：两个元素互相都“不小于”对方，就被视为当前比较器下相等。

SliceStable 会复制原切片吗？

不会。它会在原切片上排序；需要保留原始输入时，应先复制切片再排序。

为什么结果看起来每次都一样，还要用稳定排序？

一次运行的偶然顺序不是 API 保证。涉及分页、合并、刷新或审计展示时，应选择稳定排序或补齐明确的次键。

参考资料：https://pkg.go.dev/sort、https://go.dev/src/sort/slice.go。