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 还不够！如果多个记录 <code>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 同样不稳定：相同 score 的行物理存储顺序可能随 VACUUM、主从同步延迟、索引重建而变化。所以服务端内存排序也必须同步策略。
- 线上建议：无论 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：
立即学习“go语言免费学习笔记（深入）”；
- 排序结果仅用于临时展示（如 CLI 工具输出），不涉及后续分页、导出、状态保持
- 业务逻辑明确允许相等元素顺序浮动（例如：排行榜只显示 Top 10，同分者不区分先后）
- 切片元素不含唯一标识字段，或你根本不想/不能引入辅助排序依据
- 压测确认排序耗时成为瓶颈，且
sort.SliceStable真实拖慢了关键路径
现实中，绝大多数 Web API、后台任务、配置管理场景，都应该默认选 sort.SliceStable —— 它带来的确定性，远比那一点性能差异重要得多。
