Go sort.SliceStable 怎么按多个字段保持原顺序

可以把 sort.SliceStable 的多字段排序理解成“先比主字段，再比次字段；所有参与比较的字段都相等时，不再交换”。这样既能得到确定的字段顺序，又能让相等记录继续保持进入切片时的相对顺序。

一、先把“稳定”拆成两个规则

假设工单要先按 Team 升序，再按 Priority 升序。两条工单的这两个字段都相同时，稳定排序不会替你凭空决定先后，而是保留它们在原切片中的顺序。比如编号 A 先于 C 出现，排序后 A 仍然先于 C。

这里有两个容易混淆的概念：字段优先级决定“不同值怎么排”，稳定性决定“比较结果相等时怎么办”。前者写进比较器，后者由 SliceStable 负责。

二、用一个复合比较器按多个字段排序

实际写法通常比“先排序再补字段”更直观。下面把团队作为主字段、优先级作为次字段，优先级数字越小越紧急：

type Ticket struct {
    Team     string
    Priority int
    ID       string
}

sort.SliceStable(tickets, func(i, j int) bool {
    left, right := tickets[i], tickets[j]

    // 先比较主字段，主字段不同就不再看后面的条件。
    if left.Team != right.Team {
        return left.Team 

输入顺序若是 api/2/A、web/1/B、api/2/C、api/1/D、web/1/E，结果会先出现 api/1/D，接着是 api/2/A、api/2/C，最后是 web/1/B、web/1/E。其中 A 在 C 前、B 在 E 前，正是稳定性产生的效果。

三、需要分层写条件时，顺序要反过来

如果业务逻辑已经拆成几个独立排序动作，也可以连续调用 sort.SliceStable。关键是先排低优先级字段，再排高优先级字段。第二次排序遇到主字段相等的记录时，会保留第一次排序得到的次序。

// 先按低优先级字段排序，让相同 Team 内部形成 Priority 顺序。
sort.SliceStable(tickets, func(i, j int) bool {
    return tickets[i].Priority 

这种写法适合每个排序条件需要单独复用或动态组合的场景。条件较少时，一个复合比较器更容易审查；条件很多时，可以把每个字段比较提取为小函数，但仍要保持“字段相等就继续、全部相等就返回 false”的约定。

四、降序和边界条件要单独检查

• 降序不要改稳定语义。例如优先级越大越靠前时只把该分支改成 left.Priority > right.Priority，相等时仍然返回 false。
• 不要用非严格比较。left.Team 在两边相等时会返回 true，破坏比较器应有的严格顺序，也会让相等项的稳定性失去意义。
• 先定义空值规则。字符串空值、指针字段或时间字段如果存在业务特殊含义，应在比较器里明确放前还是放后，不要依赖偶然的默认值。
• 排序会修改原切片。如果还要保留输入顺序用于审计或回显，先复制一份切片，再对副本调用 sort.SliceStable。

相关问题

sort.SliceStable 和 sort.Slice 最大区别是什么？

两者都使用回调比较元素，但 SliceStable 明确保持比较结果相等元素的原始相对顺序；需要这个保证时不要把普通排序当成稳定排序。

三个字段都相等时要不要再比较 ID？

如果业务要求最终顺序完全确定，可以把 ID 作为最后一个业务字段；如果要保留导入顺序，就不要补 ID 比较，让稳定排序保留原顺序。

多次稳定排序一定比一个比较器好吗？

不一定。字段固定时一个复合比较器更集中；条件需要动态拼装时，多次稳定排序更容易组合，但必须遵守先低优先级、后高优先级。

官方 sort.SliceStable 文档对稳定性的定义很明确：比较结果相等的元素会保持原有顺序。把这条规则和字段优先级分开写，复合排序就不容易出现“字段对了、相等项乱了”的问题。