Go 中需要保留相同排序键记录的先后关系时，可以使用 slices.SortStableFunc，并让比较函数在键相同时返回 0。它保留的是本次排序前切片中这些记录的相对次序，不会凭空恢复业务上的到达时间，也不能修复上游随机排列。
考虑一个批量任务列表：按优先级从小到大展示，同优先级继续沿用接收次序。单机小批量时这件事很直接；接入多个分片后，如果收集顺序已经变化，仅替换排序 API 就不够了。下面用一个原创的任务模型拆开这两个问题，不把示例包装成真实线上复盘。
标准库官方入口：https://pkg.go.dev/slices。
先定义同键记录究竟保留哪一种顺序
任务有 ID 和 Priority 两个字段。业务约定优先级数字越小越靠前，同优先级沿用输入位置。T-41、T-43、T-45 都属于优先级 2；如果它们在输入中按这个次序出现，最终列表中这三者的相对关系也应保持不变。其他优先级的记录可以插入它们之前，但不能把三者互相颠倒。
“相同”由比较函数定义，而不是要求整个结构体相等。只比较 Priority，就把 Priority 相同的记录视为等价；同时比较 ID，则这些不同 ID 的记录不再等价。把这个约定写进函数名称，比笼统要求“稳定一点”更容易沟通。
SortStableFunc 官方文档明确保留等价元素原有次序；SortFunc 则没有稳定性保证。一次观察中没有发生换位，不能证明不稳定排序在以后也会保留次序。
把比较函数和稳定排序放在同一个边界
以下完整示例采用 Go 1.21 起提供的 slices、cmp 包。比较函数只比较整数优先级，不使用减法，避免极端整数相减溢出造成比较符号错误。克隆发生在排序之前，因此调用方仍能保留原切片的排列。
package main
import (
"cmp"
"fmt"
"slices"
)
// Task 的输入位置代表本批记录的接收次序。
type Task struct {
ID string
Priority int
}
// ByPriority 只定义主键，相同优先级必须返回零。
func ByPriority(a, b Task) int {
return cmp.Compare(a.Priority, b.Priority)
}
// StableByPriority 复制切片，避免改动调用方的元素次序。
func StableByPriority(input []Task) []Task {
result := slices.Clone(input)
slices.SortStableFunc(result, ByPriority)
return result
}
func main() {
input := []Task{
{ID: "T-41", Priority: 2},
{ID: "T-42", Priority: 1},
{ID: "T-43", Priority: 2},
{ID: "T-44", Priority: 1},
{ID: "T-45", Priority: 2},
}
result := StableByPriority(input)
// 这里只展示排序方案，不代表已在本文环境执行。
fmt.Println(result)
fmt.Println(input)
}
按这里的固定输入推导，result 的 ID 次序应为 T-42、T-44、T-41、T-43、T-45，input 仍保留 T-41 到 T-45 的原次序。这是代码语义的预期，不是本文执行得到的日志。
比较器应定义一致的严格弱序；不能读取不断变化的外部状态，也不能在比较时修改排序字段。同键返回零，反向比较应有相反的大小关系，并且大小关系保持传递。用 cmp.Compare 比较这个整数键，可以避免自行拼装比较分支。
slices.Clone 只提供浅复制。如果 Task 后来包含指针、map 或其他切片，里面引用的对象仍可能共享；这里只把结构体值在新切片中重新排列。排序期间也不要让其他 goroutine 并发写入这些记录。
输入规模变大后不要复制错误的前提
旧方案真正可能撑不住的，不只是排序函数：分片并发返回后按完成先后拼接，会改变同键记录的输入次序；每个分片各排一次再简单拼接，也不能得到全局有序列表。这些是数据组织的约束，不是稳定排序实现的缺陷。
如果业务仍要求接收次序，就必须在接收边界记录可比较的业务序号，并明确分片之间如何统一这个序号。单个 worker 的局部递增值不能直接代表全局顺序。等所有数据汇总后统一稳定排序适用于能容纳完整数据集的场景；无法一次装入内存时，需要另外设计外部排序或带完整比较规则的有序归并，不能把批内保证扩展成全局保证。
代码中的克隆需要与元素数量成正比的额外切片存储。若调用方已明确移交独占所有权，可以直接原地排序来减少这份复制，但应让函数契约体现“会改变输入”，而不是悄悄删掉 Clone。
sort.Stable 文档分别列出了比较次数和交换次数的复杂度；不要把比较次数等同于端到端耗时。记录很大、比较键需要昂贵转换或批量增大时，都应在实际负载里观察排序耗时、分配量和复制开销。本文没有跑基准，也不提供虚构的提速百分比。
跨请求一致性需要明确的次级键
如果产品要的是“每次刷新同优先级都按 ID 排”，目标已经从保留输入次序变成确定性排序。此时把唯一且持久的 ID 作为次级键即可，没必要依赖稳定排序保存一个并不可靠的输入顺序。
// ByPriorityThenID 为唯一 ID 的记录规定跨批次可复现的顺序。
// 该函数与前文 Task 定义及 cmp、slices 导入配合使用。
func ByPriorityThenID(a, b Task) int {
if order := cmp.Compare(a.Priority, b.Priority); order != 0 {
return order
}
return cmp.Compare(a.ID, b.ID)
}
// DeterministicByPriority 不再承诺同优先级记录保持接收先后。
func DeterministicByPriority(input []Task) []Task {
result := slices.Clone(input)
slices.SortFunc(result, ByPriorityThenID)
return result
}
这个片段按字符串字典序比较 ID，不是按 ID 中数字的大小排序。业务若需要数值序号，应单独保存整数序号，不要依赖可变长度字符串的外观。ID 唯一的前提成立时，主键与 ID 能区分不同记录；若允许重复 ID，就还需要定义进一步的顺序规则。
Go 语言规范的 range 规则不保证 map 的遍历次序。从 map 收集 Task 后只按 Priority 稳定排序，可能在每次收集中保留不同的同键次序。为这种输入增加明确次级键，才是在解决跨请求一致性。
即使完整比较键确定，在变化中的数据集上做分页仍可能因新增、删除而移动记录。快照、游标及查询端排序必须配合设计，不能因为本地排序可复现，就声称分页不会重复或漏项。
上线观察的是顺序契约而非一次截图
落地时先在接口约定中二选一：保留同键输入关系，或者按固定次级键排序。不要让两个调用方用相同函数名却期待不同结果。对输入次序有要求的调用方，需要说明是谁建立次序、排序前是否已经经过 map、并发收集或其他重排。
可把原输入位置作为临时核对信息，在业务自己的回归样本中关注三件事：排序键是否有序，同键记录原位置是否保持递增，输入切片是否按函数约定保留。仅检查“主键已经升序”不足以证明稳定性。覆盖大量重复键、全部同键、空切片和单元素等情况，比只看五条示例更能暴露契约误解。
上线后的观察项也应跟随这份契约：同键次序投诉或回归失败、请求数据量、排序耗时、内存分配以及上游收集方式。这里给的是建议观察项，不是宣称已经完成上线或取得某组指标。若复制成本成为压力，先确认所有权能否转移，再决定改原地排序；若跨分片顺序不一致，先修复键与输入模型，再谈更换算法。
旧代码替换时常遇到的三个问题
老代码使用 sort.Slice，最小改动是什么？
可改用 sort.SliceStable 并保留正确的 less 比较器。相同键时两个方向都应为 false，不能使用小于等于。已有 sort.Interface 的代码也可使用 sort.Stable。迁移到 slices.SortStableFunc 时注意回调由下标和布尔值改为元素值和负、零、正整数。
同键想保留原顺序，却在比较器里加 ID，可以吗？
那会改变等价定义，最终同优先级按照 ID 排，而不是按照输入先后排。应先确认业务目标，再选择比较器；稳定算法不会覆盖你明确写出的次级排序规则。
多字段能通过多次稳定排序完成吗？
可以按低优先级字段在先、高优先级字段在后的顺序多次稳定排序，但每次都有完整排序成本，也更依赖维护者理解字段优先级。多数业务用一个按字段逐级比较的函数更直观；所有字段都相等时返回零，再由稳定排序保存剩余输入关系。
最终选择不复杂：保留本次输入的同键关系，用稳定排序；固定不同请求间的同键结果，用明确、持久且足以区分记录的次级键。规模扩大时，额外需要把这个规则延伸到收集、归并与分页边界，不能只替换函数名称。
Go HTTP 服务怎样优雅关闭 
