javascript 中应直接使用 array.prototype.sort()，因其在现代引擎中已优化为 timsort 或混合排序，平均 o(n log n)，手写算法反而增加风险；关键在于正确编写比较函数，如数字排序需用 (a, b) => a - b，避免不一致或耗时操作。
JavaScript 中没有“高效排序算法”的通用实现——Array.prototype.sort() 本身已基于 Timsort（V8）或 QuickSort（部分旧引擎），平均时间复杂度 O(n log n)，实际场景下直接调用它就是最高效的选择。手写快排、归并等，除非有特殊约束（如稳定排序、内存受限、自定义比较逻辑需极致控制），否则纯属增加 bug 风险和维护成本。
为什么不该自己实现 sort 的底层逻辑
现代 JavaScript 引擎对 sort 做了深度优化：
- V8（Chrome / Node.js）使用
Timsort：对部分有序数组接近 O(n)，且稳定； - SpiderMonkey（Firefox）和 JavaScriptCore（Safari）也早已弃用纯
Quicksort，改用混合策略（introsort + insertion sort 小数组）； -
sort的比较函数调用开销被 JIT 编译器大幅削减，而手写递归/迭代版本往往触发更多 GC 或无法内联； - 你写的“优化版快排”大概率比不过引擎内置实现，尤其在真实数据分布（含重复、局部有序、小数组）下。
sort 正确用法与常见翻车点
真正影响排序效率和正确性的，是传给 sort 的比较函数写法，而非算法本身：
- 数字排序必须显式提供比较函数：
[3, 10, 1].sort((a, b) => a - b)，否则按字符串字典序排成[1, 10, 3]； - 避免在比较函数中做耗时操作（如
JSON.stringify、DOM 查询、正则匹配），这会放大 O(n log n) 的常数因子； - 确保比较函数满足“一致性”：对同一对值，多次调用必须返回相同结果；否则引擎可能陷入无限循环或抛出
RangeError: Maximum call stack size exceeded； - 若需稳定排序（相等元素相对位置不变），不要依赖旧版 V8（sort——应先用索引标记，再按主键+索引双条件排序。
真需要手写时，什么场景值得考虑
仅当出现以下明确约束时，才应绕过 sort：
立即学习“Java免费学习笔记（深入）”；
- 输入是超大 TypedArray（如
Float64Array），且需避免转换为普通数组带来的内存拷贝；此时可用WebAssembly实现或partition+ 原地堆排序； - 排序过程需中断/暂停（如 UI 响应优先级调度），需把算法拆成可恢复的 generator（例如分治每层 yield 一次）；
- 比较逻辑极度复杂且高频调用，已通过性能分析确认比较函数占总耗时 80%+，此时可预计算 key（
map提前转成数字/字符串），再用简单比较函数； - 教学或面试要求明确手写——那就选
quicksort（易懂）或mergesort（稳定、易改造成外部排序），但务必注明“仅用于演示”。
真正卡性能的，从来不是“该用快排还是归并”，而是没意识到 sort 已经够快，却把时间花在错误的比较函数、冗余的数据转换或过早优化上。
