JS数组sort排序陷阱：数字排序错误原因及正确写法

一、现象表现：默认 sort() 对数字排序的怪异现象

很多初学者在需要对数值进行简单排序时，往往会直接调用原生数组的 sort() 方法。看下面这段看似理所当然的代码：

// 示例：直接调用 sort()
const scores = [10, 5, 40, 25, 1000, 1];
scores.sort();

console.log(scores);
// 实际输出: [1, 10, 1000, 25, 40, 5]
// 期望输出: [1, 5, 10, 25, 40, 1000]

运行结果完全打乱了数值大小关系：

• 原本远大于 5 的 1000，竟然被排在了 5 的前面；
• 原本仅次于 1 的 5，反而被挤到了整个数组的最末尾；
• 两位数 40 排在了 5 之前，而 25 又插在 1000 与 40 中间。

这种既不是升序也不是降序的排列，并非 JavaScript 引擎的随机故障，而是严格遵循语言标准的必然结果。

二、原理剖析：为什么数字会被排成这种顺序？

根据 ECMAScript 规范定义，当调用 Array.prototype.sort() 且没有传入比较函数时，排序算法内部会执行以下两步转换：

1. 隐式字符串化（ToString 转换）：对参与比较的元素调用内部的 ToString(x) 抽象操作，将数值临时转为字符串。因此，1000 变成了 "1000"，5 变成了 "5"。
2. 按 UTF-16 代码单元逐位比对（字典序）：字符串的比较并不衡量整体长度或实际数值量级，而是从第一个字符开始，依次比较字符对应的 UTF-16 编码点数值。

我们可以通过原生方法 charCodeAt(0) 查看各首位字符的编码点：

console.log("1".charCodeAt(0)); // 49
console.log("2".charCodeAt(0)); // 50
console.log("4".charCodeAt(0)); // 52
console.log("5".charCodeAt(0)); // 53

在逐位对比时：

• "1000" 的首字符是 "1"（编码值 49），而 "5" 的首字符是 "5"（编码值 53）。因为 49 < 53，所以引擎判定 "1000" < "5" 成立；
• 同样地，"40" 的首字符编码值是 52，小于 "5" 的 53，因此 "40" < "5" 也成立；
• 这种排列规则与英文字典的查词逻辑完全一致：无论单词 "apple" 有多长，在字典中它必定排在单个字母 "b" 的前面。

三、正确写法：使用数值比较函数（Compare Function）

为了让 sort() 按照真实数值大小工作，我们需要向其传递一个比较函数：arr.sort(compareFunction)。该函数接收两个待比较的元素 a 和 b，并依据其返回值的符号来决定相对位置。

1. 比较函数的三态返回值规则

• 返回值 < 0（负数）：表示 a 应该排在 b 之前（在升序排列中即 a < b）；
• 返回值 === 0：表示 a 和 b 等价，相对位置保持不变（ECMAScript 2019 规范起要求排序算法必须是稳定的）；
• 返回值 > 0（正数）：表示 b 应该排在 a 之前（在升序排列中即 a > b，需要调换位置）。

2. 升序与降序的标准代码

利用两数相减的结果自然满足正负特性的规律，我们可以用极简的箭头函数实现排序：

const numbers = [10, 5, 40, 25, 1000, 1];

// 1. 标准升序（从低到高）
// 当 a < b 时，a - b < 0，a 排在 b 前面
const ascending = [...numbers].sort((a, b) => a - b);
console.log(ascending); 
// 输出: [1, 5, 10, 25, 40, 1000]

// 2. 标准降序（从高到低）
// 当 b > a 时，b - a > 0，b 排在 a 前面
const descending = [...numbers].sort((a, b) => b - a);
console.log(descending); 
// 输出: [1000, 40, 25, 10, 5, 1]

3. 对象数组中基于数值属性的排序

在日常业务中，最常见的需求是对接口返回的对象列表进行排序，例如根据商品价格、用户积分或时间戳排序。写法同样是提取对应属性后做差：

const products = [
  { id: 101, name: "键盘", price: 299 },
  { id: 102, name: "鼠标", price: 89 },
  { id: 103, name: "显示器", price: 1299 },
  { id: 104, name: "扩展坞", price: 159 }
];

// 按价格升序排列
products.sort((a, b) => a.price - b.price);

console.log(products.map(p => `${p.name}: ¥${p.price}`));
// 输出: ['鼠标: ¥89', '扩展坞: ¥159', '键盘: ¥299', '显示器: ¥1299']

四、进阶避坑：3 个容易忽略的高危陷阱与防护策略

掌握了 (a, b) => a - b 之后，还必须注意以下三个容易引发线上隐蔽 Bug 的陷阱：

陷阱 1：原地修改（In-Place Mutation）破坏原数据源

sort() 方法会直接修改调用它的原数组，并返回原数组的引用，而不是生成新数组。如果在 Vue 或 React 这类强调不可变数据（Immutability）的框架中，直接对组件的 props 或响应式状态调用 sort()，会导致副作用失控或组件视图不更新。

const original = [3, 1, 2];

// 现代浏览器及 Node.js 20+ 推荐：toSorted（返回全新数组，原数组不变）
const modernSorted = original.toSorted((a, b) => a - b);
console.log(original);     // [3, 1, 2] （保持不变）
console.log(modernSorted); // [1, 2, 3]

// 兼容老版本环境写法：展开运算符或 slice 复制
const legacySorted = [...original].sort((a, b) => a - b);

陷阱 2：直接减法导致的数值溢出与 NaN 比较失效

a - b 的简便写法虽然常用，但在处理特殊数值时存在严重隐患：

• 无穷大相减：Infinity - Infinity 会计算为 NaN；
• 混入非数值或 NaN：任何数字与 NaN 进行减法都会得到 NaN。而一旦比较函数返回 NaN，排序算法便无法确定两个元素的相对关系，导致部分元素被跳过，最终破坏整体有序性；
• 超出安全整数范围的大数相减：极端大数跨度可能造成浮点数精度截断或下溢。

// 面对极端数值时的健壮比较写法：使用显式关系判断
function safeNumericCompare(a, b) {
  // 1. 若存在 NaN，将其统一推向末端
  if (Number.isNaN(a)) return 1;
  if (Number.isNaN(b)) return -1;
  
  // 2. 显式大小比对，规避减法溢出
  if (a < b) return -1;
  if (a > b) return 1;
  return 0;
}

const riskyList = [10, Infinity, 2, -Infinity, 5];
riskyList.sort(safeNumericCompare);
console.log(riskyList);
// 输出: [-Infinity, 2, 5, 10, Infinity]

陷阱 3：undefined 与稀疏数组的特殊表现

ECMAScript 规范专门针对 undefined 制定了规则：所有 undefined 元素都会被统一移到数组的最末端。值得注意的是，这些 undefined 元素根本不会被传入用户自定义的 compareFunction 中。稀疏数组中未初始化的“空槽”（empty slots）也是同样的行为，会被转为 undefined 并聚集在数组末尾。

五、知识总结与全景速查清单

为了在不同场景下快速选用最合适、最健壮的排序方案，建议参考下表及全景速查图：