ES2019sort算法稳定性详解

ES2019 正式要求 Array.prototype.sort 必须是稳定排序，但真正的稳定性并非浏览器版本达标就自动生效——它高度依赖你编写的 compareFn 是否严格返回 -1/0/1，且仅在逻辑相等（即返回 0）时才保证原有顺序；Chrome 70+、Firefox 63+、Safari 14+ 和 Node.js v12.0.0+ 已合规，但 Safari 13 及更早版本仍使用不稳定的快排，而常见错误如布尔值隐式转换、未处理边界值或误用默认字符串排序，都会让“看似正确”的代码在实际运行中打乱数据顺序；最可靠的方式是用带唯一序号的对象数组实测行为，而非依赖 UA 判断，同时可通过添加临时索引字段手动保序，兼顾兼容性与确定性。

sort 方法在 Chrome/Firefox/Safari 中是否真稳定

ES2019 正式要求 Array.prototype.sort 必须是稳定排序，但“符合标准”不等于“你写的代码就稳定”——关键看比较函数是否严格遵守规范。Chrome 70+、Firefox 63+、Safari 14+ 均已达标，但 Safari 13 及更早版本仍用不稳定的 quicksort（哪怕你传了 compareFn）。

常见错误现象：[{k:1,v:'a'},{k:1,v:'b'},{k:2,v:'c'}].sort((a,b) => a.k - b.k) 在 Safari 13 下可能打乱 v 的原始顺序；而同一段代码在 Chrome 80+ 中能保持 v:'a' 在 v:'b' 前。

• 判断当前环境是否真稳定：运行 [{x:1,y:0},{x:1,y:1},{x:2,y:2}].sort((a,b) => a.x - b.x).map(i => i.y)，若返回 [0,1,2] 才算稳定
• 不要依赖浏览器 UA 判断，用实际行为检测更可靠
• Node.js 从 v12.0.0 起也满足 ES2019 稳定性要求，但 v10.x 不保证

写 compareFn 时最容易破坏稳定性的写法

稳定性只在比较结果为 0 时才有意义——如果两个元素“相等”，它们的相对位置必须保留。但很多 compareFn 在逻辑上把本该返回 0 的情况错判为正/负，直接让引擎失去稳定排序依据。

典型翻车现场：(a,b) => a.id === b.id ? 0 : a.id > b.id ? 1 : -1 看似严谨，但 a.id > b.id 返回布尔值，参与数值运算会隐式转成 1 或 0，导致 false ? 1 : -1 实际恒为 -1，所有比较都变成单向偏移。

• 必须确保 compareFn(a,b) === 0 当且仅当 a 和 b 在排序维度上“等价”
• 避免用 >/< 直接返回布尔值，改用减法或三元明确返回 -1/0/1
• 对字符串排序慎用 localeCompare：它本身稳定，但若混用大小写敏感/不敏感逻辑，可能让语义相等的项被判定为不等

需要稳定排序但又不敢信 sort 的替代方案

不是所有场景都值得为兼容旧 Safari 写降级逻辑。如果你只处理几百条数据、且明确知道用户用的是现代浏览器，直接用 sort 更轻量。但若业务要求强一致（比如财务流水按时间+ID 双重排序），建议加一层防御。

一个够用的兜底策略：给原数组每个元素打上原始索引，排序时把索引作为次要比较项。

arr.map((item, idx) => ({ ...item, __idx: idx }))
   .sort((a, b) => {
     const byTime = a.time - b.time;
     return byTime !== 0 ? byTime : a.__idx - b.__idx;
   })
   .map(({ __idx, ...rest }) => rest);

• 这个模式不依赖引擎稳定性，纯靠逻辑保序
• __idx 是临时字段，别和业务字段名冲突
• 性能影响有限：V8 对带额外属性的对象排序优化很好，千条以内几乎无感
• 注意内存：如果 arr 很大且只用一次，记得及时丢弃中间对象

MDN 上说“stable since ES2019”，为什么我测出来还是不稳定

大概率是你测的方式有问题。ES2019 规范只约束“当 compareFn(a,b) === 0 时，a 和 b 的相对顺序不变”，它不管 compareFn 本身写得对不对，也不管你有没有传 compareFn。

没传 compareFn 时，sort() 按字符串 Unicode 码点排序，此时稳定性依然受规范约束——但如果你排序的是数字数组 [10, 2, 30]，默认行为会转成 ['10','2','30'] 再比，结果是 [10, 2, 30]（因为 '10' < '2'），这看起来像“不稳定”，其实是你没理解默认行为。

• 测试前先确认：是否传了 compareFn？它的返回值是否严格为 -1/0/1？
• 用对象数组测，别用纯数字/字符串数组——后者容易混淆“语义相等”和“字面量相等”
• 不同浏览器对 undefined、null、NaN 的处理仍有差异，这些值参与比较时可能触发非预期分支

真正难搞的从来不是标准本身，而是我们总在用“我以为”的 compareFn 去验证“它应该”的稳定性。

今天关于《ES2019sort算法稳定性详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！