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 做了深度优化:
Timsort:对部分有序数组接近 O(n),且稳定;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;仅当出现以下明确约束时,才应绕过 sort:

Float64Array),且需避免转换为普通数组带来的内存拷贝;此时可用 WebAssembly 实现或 partition + 原地堆排序;map 提前转成数字/字符串),再用简单比较函数;quicksort(易懂)或 mergesort(稳定、易改造成外部排序),但务必注明“仅用于演示”。真正卡性能的,从来不是“该用快排还是归并”,而是没意识到 sort 已经够快,却把时间花在错误的比较函数、冗余的数据转换或过早优化上。