别让 sort() 误导你：JS 数组自定义排序的实战逻辑与避坑指南

刚入行时，我也以为 array.sort() 就是个简单的“一键排好”，直到接手一个电商后台需求，才发现现实远非如此简单。当数据从简单的数字列表变成复杂的商品对象，还要兼顾价格、库存、上架时间多重维度时，默认的排序逻辑往往会带来意想不到的 Bug。

很多人在这一步栽跟头，核心原因是对回调函数的返回值理解不够透彻。sort() 的回调函数必须返回数字，而不是布尔值。如果写成 (a, b) => a > b，在某些浏览器版本里可能导致排序错乱或性能下降。正确的做法是利用数值比较：返回负数表示 a 排在 b 前面，正数则相反，0 表示相等。这个看似基础的规定，却是后续复杂逻辑的基石。

面对对象数组，直接减法是行不通的。比如要按用户等级和注册时间双重排序，不能简单地写两段代码，而是要利用逻辑运算符短路特性：a.level - b.level || a.regTime - b.regTime。这样当前者不等时直接输出结果，相等时才比较下一个字段。这种写法比层层嵌套的 if 更简洁，也更容易维护。不过要注意，如果是字符串比较，千万别用减法，得用 localeCompare() 方法处理中文或特殊字符的编码问题，否则会出现字典序混乱的情况。

另一个高频痛点是空值的处理。业务数据难免会有 null 或 undefined，如果不加处理直接参与排序，它们要么跑到最前面，要么被扔到最后，甚至引发程序崩溃。比较稳妥的策略是在回调内部先判断：if (!a.priority && !b.priority) return 0; if (!a.priority) return 1; if (!b.priority) return -1;。明确定义空值是靠前还是靠后，把不确定性关在逻辑门外，页面渲染才不会突然跳变。

还得提一嘴原数组修改的问题。sort() 是原地排序，会直接改变源数组。在前端框架开发中，这往往是响应式数据丢失或者状态污染的黑洞。建议在调用前通过扩展运算符创建副本，例如 [...originalArray].sort(...)，既能保证逻辑纯净，也能避免意外副作用。虽然多了一点点内存开销，但在维护性面前，这点成本完全值得。

到了 ES2019 之后，主流引擎如 Chrome 的 V8 已经实现了稳定排序，相同元素的相对顺序会被保留。但如果你还需要兼容老旧环境，或者对特定对象的稳定性有极高要求，最好在逻辑层面做额外标识，不要完全依赖底层实现。

排序不仅仅是语法题，更是业务逻辑的体现。清晰的回调函数、严谨的空值兜底、以及对副作用的控制，才是写出健壮代码的关键。下次再写排序时，不妨多花两分钟审视一下数据场景，别让一个简单的 API 成为线上事故的导火索。