JavaScript手写排序关键在理解适用边界与翻车点：冒泡适合教学但O(n²)不可用于真实数据；注意比较函数返回值类型、对象属性存在性；V8对≤10元素自动用插入排序；选择算法需据场景权衡性能、稳定性与调试需求。
JavaScript 里实现排序算法，不一定要自己写 sort() 的底层逻辑，但真要手写（比如面试、教学、或特殊比较规则），关键不是“背代码”，而是理解每种算法的适用边界和常见翻车点。
冒泡排序：适合教学，但千万别用在真实数据上
它每次只比较相邻元素并交换，稳定、易懂，但时间复杂度固定是 O(n²)，1000 个元素就要百万级比较。
- 容易漏掉内层循环的边界控制，比如写成
for (let j = 0; j 会导致越界或重复比较 - 优化点：加一个
swapped标志位，某轮没交换就提前退出——但这对随机大数据几乎没用 - 实际场景极少：仅用于小数组（
快速排序：手写高频选择，但递归深度和基准选错会崩
平均 O(n log n)，原地排序，JS 中最常被手写的“高性能”方案。但默认递归实现遇到已排序数组可能退化成 O(n²)，且栈溢出风险真实存在。
- 基准（pivot）别总选
arr[0]或arr[arr.length - 1]，用三数取中（首、中、尾）更稳 - 小数组（如长度
- 严格模式下，V8 引擎对长递归有调用栈限制；生产环境建议改用迭代版（用显式栈模拟递归）
- 注意：JS 数组是稀疏的，
arr.length不代表所有索引都有值，手写时得用in或hasOwnProperty判断有效性
归并排序：稳定且可预测，适合大数组或链表模拟
稳定排序，时间复杂度严格 O(n log n)，不依赖输入分布。缺点是需要 O(n) 额外空间——对超大数组可能触发 GC 压力。
- 合并过程容易写错边界：比如
leftIndex 和rightIndex 漏判，导致部分元素丢失 - 若处理的是类数组对象（如
arguments、DOM List），需先用Array.from()或展开语法转成真数组，否则.slice()可能失效 - Node.js 流式处理或前端分页大数据时，可改造为“外部归并”——分块读、排序、再合并，避免单次加载全量
直接调用 Array.prototype.sort()：最常用，但比较函数写错就静默失败
浏览器和 Node.js 的 sort() 底层是混合排序（快排 + 插入 + 归并），性能可靠，但默认按字符串 Unicode 码点排序，对数字就是灾难。
- 数字排序必须传比较函数：
[3, 10, 1].sort((a, b) => a - b)，写成(a, b) => a > b会返回布尔值，导致结果不可预测 - 对象数组排序注意属性是否存在：
arr.sort((a, b) => (a.name || '').localeCompare(b.name || ''))，避免undefined参与比较 - V8 在 Chrome 70+ 后对小数组（≤10）自动切插入排序，所以不用刻意优化小数据场景
真正难的不是写出能跑的排序，而是判断该用哪个——比如 UI 表格实时排序，优先选 sort() 加防抖；后端导出百万行 CSV 前预处理，就得评估内存和稳定性，可能选迭代快排或外部归并；而调试时想看中间步骤，反而得用最慢的冒泡来“可视化”交换过程。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
