<p>bubbleSort 仅适用于长度≤10且基本有序的数组；需稳定排序、比较函数有副作用、大量重复数据、排序后需二分查找但无法保证有序时，应替换原生 sort()；binarySearch 需防溢出，推荐 low + Math.floor((high - low) / 2)，返回值依场景选 index 或 Boolean。</p>
bubbleSort 不该在生产环境用，除非数组长度 ≤ 10 且你明确知道它已基本有序。
什么时候该换掉原生 sort()？
V8 的 sort() 实际用的是 Timsort（混合插入+归并），对大多数场景足够快。但如果你遇到这些情况，就得自己实现：
- 需要稳定排序，而你传入的比较函数有副作用（比如触发 DOM 更新），
sort()可能因内部优化多次调用比较函数 - 处理大量重复数据（如日志状态字段只有 "pending"/"done"/"error"），基础
quickSort会退化到 O(n²)，应改用三路快排quickSort3Way - 排序后立刻要二分查找，而你无法保证输入一定有序——别依赖“用户说它有序”，加一层
isSorted(arr)校验更稳妥
binarySearch 写错边界就永远找不到
常见错误不是逻辑错，而是整数溢出或下标越界。Chrome 115 测试显示，low + high 在数组超 2³¹ 元素时会溢出（虽然前端几乎遇不到，但写法要严谨）。
正确写法必须用：Math.floor((low + high) / 2) 或更安全的 low + Math.floor((high - low) / 2)。后者避免溢出，也更符合语义——“从 low 开始走一半距离”。
立即学习“Java免费学习笔记（深入）”；
另外，返回值是索引还是布尔值？根据场景定：
- 做 UI 定位（如滚动到某条记录）→ 返回
index，-1 表示不存在 - 做存在性校验（如防重复提交）→ 直接返回
Boolean(index !== -1)，省去上层判断
小数组别硬套 mergeSort，插入排序反而更快
V8 引擎实测：长度 insertionSort 比 quickSort 快约 35%。这不是理论值，是真实 V8 优化行为——因为小数组的递归开销和内存分配成本超过了算法本身收益。
所以混合策略很实用：
- 拆分到子数组长度 ≤ 10 时，停止递归，改用
insertionSort - 不要手动写“if (arr.length
- 注意：
insertionSort必须是原地、无额外空间分配的版本，否则失去意义
真正容易被忽略的，是搜索前的数据就绪成本。比如你花 0.02ms 做一次 binarySearch，却用了 15ms 把接口返回的乱序列表先 sort() 一遍——这时候优化搜索毫无意义。先问清楚：这个列表是否本就该服务端排序？是否可以缓存排序结果？是否值得用 Map 建索引替代反复搜索？
