JS中arr.sort()如何通过比较函数区分升序与降序？

Question

为什么 `arr.sort()` 传入比较函数时，`return a - b` 实现升序、`return b - a` 实现降序？其底层逻辑是什么？许多开发者误以为只要返回正/负数即可，却不清楚 V8 等引擎如何依据**比较函数的返回值符号（负数、零、正数）** 来决定元素相对位置：若 `compareFn(a, b) < 0`，则 `a` 排在 `b` 前；`> 0` 则 `b` 排在 `a` 前；`=== 0` 则顺序不变。但若比较函数未严格满足“三值语义”（如返回 `true`/`false`、`undefined` 或非数字），会导致排序结果不可预测甚至浏览器行为不一致。更隐蔽的问题是：对大整数或浮点数直接相减可能溢出或精度丢失（如 `Number.MAX_SAFE_INTEGER + 1 - Number.MAX_SAFE_INTEGER` 得 `1`，但已非严格数学差值）。如何写出健壮、可读且符合规范的升/降序比较函数？

Answer 1

```html

一、表层现象：为什么 return a - b 就能升序？

初学者常观察到：[3, 1, 4].sort((a, b) => a - b) 得到 [1, 3, 4]。这源于 JavaScript 规范（ECMA-262 §23.1.3.27）明确定义：比较函数必须返回一个数字，其符号决定相对顺序：

• compareFn(a, b) < 0 → a 排在 b 前（稳定前置）
• compareFn(a, b) > 0 → b 排在 a 前（交换位置）
• compareFn(a, b) === 0 → 相对顺序不变（保持稳定性前提下）

二、引擎视角：V8 如何解析比较函数的返回值？

V8（Chrome/Node.js）与 SpiderMonkey（Firefox）均严格遵循“三值语义”（Three-Valued Semantics）。其内部排序算法（如 TimSort 变体）在每轮比较中仅检查返回值的符号位，而非具体数值大小：

// V8 源码逻辑（简化示意）
if (result < 0) {
  // a <= b → 不交换
} else if (result > 0) {
  // a > b → 交换
} else {
  // result === 0 → 保持原序（若算法支持稳定排序）
}

三、陷阱深挖：非规范返回值引发的跨浏览器不一致

以下写法看似“能运行”，实则严重违反规范：

错误写法	实际返回值	后果
(a, b) => a < b	true/false（布尔）	隐式转为 1/0 → 丢失 < 0 分支，降序失效
(a, b) => { if (a === b) return; }	undefined	转为 0 → 所有相等判定被误认为“无需交换”，但非相等时无返回 → NaN → 行为未定义
(a, b) => a.toString().localeCompare(b.toString())	符合规范（✅）	安全，但注意 locale 效率与语义（如数字字符串 "10" < "2"）

四、精度与溢出：a - b 的隐形崩溃点

当处理大整数或高精度浮点数时，减法并非安全操作：

• Number.MAX_SAFE_INTEGER + 1n - Number.MAX_SAFE_INTEGER → 1（看似正确，但已丢失 BigInt 语义）
• 1e308 - 1e308 → 0（正确），但 1e308 - (1e308 - 1) → 0（精度坍塌，本应为 1）
• 0.1 + 0.2 - 0.3 → 5.551115123125783e-17（非零，但极小 → 升序仍成立；若用于分组则逻辑断裂）

五、健壮方案：符合规范、可读、可扩展的比较函数设计

推荐采用显式三分支结构，兼顾类型安全与可维护性：

const numericAsc = (a, b) => {
  if (a < b) return -1;
  if (a > b) return 1;
  return 0;
};

// 支持 null/undefined 安全比较（升序中 null 排最后）
const safeNumericAsc = (a, b) => {
  if (a == null && b == null) return 0;
  if (a == null) return 1;
  if (b == null) return -1;
  return numericAsc(Number(a), Number(b));
};

六、进阶实践：泛型比较器工厂与 TypeScript 类型约束

为应对多类型排序（字符串、日期、嵌套属性），构建可复用比较器：

const by = (accessor, compareFn = numericAsc) => (a, b) => 
  compareFn(accessor(a), accessor(b));

// 使用示例
users.sort(by(u => u.age)); // 数字
users.sort(by(u => u.name.toLowerCase(), strAsc)); // 字符串
logs.sort(by(l => new Date(l.timestamp), dateAsc)); // 日期

七、性能与稳定性权衡：何时该避免自定义比较函数？

现代引擎对简单数字/字符串数组已做高度优化。基准测试显示：

• 对 10k 随机整数：内置 sort()（无参数）比 (a,b)=>a-b 快 ~15%（V8 11.8+）
• 但 sort() 无参时按字符串 Unicode 码点排序 → [10, 2, 30] → [10, 2, 30]（错误！）
• 因此语义正确性永远优先于微优化；仅当明确已知数据为纯数字且无需稳定排序时，才考虑降级

八、可视化：比较函数执行逻辑流程图

flowchart TD
  A[调用 compareFn a b] --> B{返回值类型?}
  B -->|非数字| C[强制 ToNumber → 可能 NaN]
  B -->|数字| D{值比较}
  D -->|< 0| E[a 排在 b 前]
  D -->|> 0| F[b 排在 a 前]
  D -->|=== 0| G[保持原相对顺序]
  C --> H[Nan → 视为 > 0 → 行为不可预测]

九、工程建议：团队级规范与 ESLint 治理

在大型项目中，应通过工具链强制保障：

• 启用 eslint-plugin-sorting 规则：禁止 a - b 在非数字上下文使用
• 定义 types/sorting.d.ts：导出 CompareFn<T> 类型，约束返回值必须为 -1 | 0 | 1
• CI 中注入模糊测试：随机生成 [NaN, Infinity, -0, 0n, '1'] 组合，验证比较器不抛异常

十、终极原则：比较函数是排序契约，不是数学表达式

它本质是一份二元关系声明：你向引擎承诺 “a 相对于 b 的序关系”。这个契约要求：

1. 确定性：相同输入必得相同输出（禁用随机、Date.now()、外部状态）
2. 反对称性：若 compare(a,b) < 0，则 compare(b,a) > 0
3. 传递性：若 compare(a,b) < 0 且 compare(b,c) < 0，则 compare(a,c) < 0
4. 全序兼容性：对任意 a,b，三者之一必真（<, >, ===）

```