sort.Slice 快但不稳定，相等元素顺序可能改变；sort.SliceStable 稳定但稍慢，保证相等元素相对顺序不变，适用于分页、虚拟滚动等需可预期序的场景。

sort.Slice 是快但“记不住顺序”的排序

当你用 sort.Slice 对结构体切片按某个字段（比如 Age）排序时，它内部用的是快速排序变种——性能好、内存省，但不保证相等元素的原始位置关系。比如两个 Age == 2 的人，原先是 {"David",2} 在前、{"Eve",2} 在后，排完可能就颠倒了。

• 适用场景：一次性展示、离线计算、结果只要“大致有序”，且你明确不关心相同值之间的先后
• 常见错误现象：分页接口第二页突然出现第一页已返回过的数据，或前端列表滚动时同分项跳来跳去
• 性能影响：比 sort.SliceStable 快约 10%–30%，尤其在大数据量（>10万）时更明显

sort.SliceStable 是“守序派”，专为分页和多级排序而生

sort.SliceStable 底层用归并排序，稳定——相等元素的相对顺序永远不变。这是它和 sort.Slice 唯一但关键的区别，不是“更好”，而是“更可预期”。

• 必须用它的场景：实现游标分页、前端虚拟滚动、消息队列调度（如 gorush 中 core/queue.go 依赖稳定性保障先入先出）
• 真实坑点：只写 sort.SliceStable(data, func(i,j int) bool { return data[i].Score 还不够！如果多个记录 Score 相同，跨请求分页仍可能错乱——必须加辅助字段（如 ID 或 CreatedAt）做二级排序
• 正确写法示例（带确定性兜底）：

  sort.SliceStable(users, func(i, j int) bool {
      if users[i].Score != users[j].Score {
          return users[i].Score < users[j].Score
      }
      return users[i].ID < users[j].ID // 确保相同分数下顺序唯一
  })

数据库分页和内存分页，稳定性要求完全一致

很多人以为“数据库 ORDER BY 就够稳”，其实不然。PostgreSQL/MySQL 单字段 ORDER BY score 同样不稳定

• 线上建议：无论 DB 层是否加了 ORDER BY score, id，Go 层都应使用 sort.SliceStable + 多字段比较逻辑，形成端到端一致性
• 兼容性注意：Go 1.8+ 才有 sort.SliceStable；旧项目升级需检查 Go 版本，否则运行时报 undefined: sort.SliceStable
• 别被“稳定=慢”吓住：实测 5 万条结构体，sort.SliceStable 耗时约 3.2ms，远低于 HTTP RTT，除非极端高频排序（如每毫秒百次），否则不必过早优化

什么时候可以放心用 sort.Slice？

只有满足全部以下条件，才推荐用 sort.Slice：

• 排序结果仅用于临时展示（如 CLI 工具输出），不涉及后续分页、导出、状态保持
• 业务逻辑明确允许相等元素顺序浮动（例如：排行榜只显示 Top 10，同分者不区分先后）
• 切片元素不含唯一标识字段，或你根本不想/不能引入辅助排序依据
• 压测确认排序耗时成为瓶颈，且 sort.SliceStable 真实拖慢了关键路径

现实中，绝大多数 Web API、后台任务、配置管理场景，都应该默认选 sort.SliceStable —— 它带来的确定性，远比那一点性能差异重要得多。