std::sort 不稳定因其底层使用 introsort（快排+堆排+插排），快排和堆排会跨距离交换等价元素；std::stable_sort 基于归并排序，合并时左优先，保证相等元素原始顺序。
std::sort 不稳定，这是标准明确规定的；需要稳定性必须换用 std::stable_sort。
std::sort 为什么不能保证相等元素的顺序
它底层多采用 introsort（快排 + 堆排 + 插入排序混合），而快排和堆排本身不具备稳定性：分区或堆调整过程会跨距离交换等价元素。比如两个 score == 85 的学生，在一次快排 pivot 划分中可能被分别甩到左右子区间，最终顺序无法还原。
- 标准只要求
std::sort满足“严格弱序”下的有序性，不承诺等价元素相对位置不变 - 即使某次运行看起来顺序没变，也不能依赖——不同 libstdc++/libc++ 实现、不同数据规模、甚至编译器优化等级都可能改变行为
- 错误现象常见于：多级排序后次级顺序错乱、日志按时间戳排序后同秒事件乱序、GUI 列表刷新后选中项偏移
std::stable_sort 的稳定性如何体现
它以归并排序（或其变种）为主流实现，核心在于“合并时左优先”：当左右子序列头元素等价，总是先取左边序列的元素，从而天然保持原始输入顺序。
- 参数签名与
std::sort完全一致：std::stable_sort(first, last)或std::stable_sort(first, last, comp) - 必须传入随机访问迭代器——
std::vector、std::deque、std::array可用；std::list要用list::sort()（自带稳定） - 示例中两个
Student{85, "Alice"}和Student{85, "Charlie"}，无论比较函数返回true还是false对它们，Alice永远排在Charlie前面
性能与内存开销的实际影响
稳定性不是免费的。std::stable_sort 通常需要 O(n) 额外空间做归并缓冲，而 std::sort 仅需 O(log n) 栈空间。
立即学习“C++免费学习笔记（深入）”；
- 小数组（std::stable_sort 避免逻辑隐患
- 大内存受限场景（嵌入式、实时系统）：若数据无重复键或顺序无关，
std::sort是更安全的选择 - 大数据量 + 内存充足：现代 libstdc++ 在可用内存足够时会自动升格为
O(n log n)时间复杂度，但依然比std::sort慢 10%~30% - 别忽略缓存效应：
std::stable_sort的归并过程跳读更频繁，L1/L2 cache miss 率可能更高
多级排序必须用 stable_sort 的典型场景
比如先按姓名升序，再按分数降序——如果第二次用 std::sort，同分者姓名顺序就丢了；而用 std::stable_sort，它只对分数重排，相同分数组内自动维持姓名升序。
- 正确做法：先按次要键（姓名）调用
std::sort或std::stable_sort，再按主键（分数）调用std::stable_sort - 错误写法：
std::sort套两层，或用std::sort做主键排序后手动稳定化 - lambda 中不要写
a.score == b.score ? a.name b.score——这看似“一次排完”，但破坏了可读性，且无法复用单维度逻辑
真正容易被忽略的是：稳定性不是“偶尔生效”的特性，而是算法契约的一部分。一旦你写了 std::stable_sort，就必须接受它的内存代价；一旦你用了 std::sort，就必须假设所有等价元素的顺序随时可能翻转——哪怕测试用例没暴露。
