Chrome 70+、Firefox 63+、Safari 14+ 及 Node.js v12.0.0+ 的 sort 方法符合 ES2019 稳定排序要求，但 Safari 13 及更早版本仍不稳定；稳定性依赖 compareFn 严格返回 -1/0/1，且仅在返回 0 时保证原序。
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 去验证“它应该”的稳定性。
