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 双重排序),建议加一层防御。 Vozo Vozo是一款强大的AI视频编辑工具,可以帮助用户轻松重写、配音和编辑视频。
相关推荐
一 乐8 小时前
人口老龄化社区服务与管理平台|基于springboot+vue的人口老龄化社区服务与管理平台(源码+数据库+文档)梓䈑8 小时前
【MySQL】表的操作(数据表的创建、查看 和 修改)Dxy12393102168 小时前
Python Tensor 向量入门:从零理解深度学习的“数据语言“light blue bird8 小时前
支组汇总主子节点工序路径图表小碗羊肉8 小时前
【Redis | 第六篇】Redisson诸葛务农9 小时前
共沸脱水技术及其在光刻胶用PGMEA纯化中的应用(中)LJianK19 小时前
服务器内存过高排查流程李白客9 小时前
SQL Server 迁移注意事项:一次的真实复盘与经验沉淀ZC跨境爬虫9 小时前
SQL学习日志 Day_3 :(SELECT查询语句入门)lld9510279 小时前
(二)从验证到执行:策略实时运行全链路