js冒泡排序优化实战：别让算法在“假有序”里空转

写前端久了，遇到小数据量排序时常会随手敲一段冒泡。老版本代码跑起来拖沓，明明数组已经排好序了，它还在死磕每一轮循环。这不是算法本身的问题，是边界监控没跟上。不聊抽象的时间复杂度，直接拆解能落地的优化路径，把多余的遍历干净利落砍掉。

基础版冒泡的核心逻辑很简单：相邻元素两两比较，逆序则交换。双层循环套着走，外层控轮次，内层跑腿。卡点全在内层的终止条件上。写成固定的 length - 1，意味着即使第一趟走完数据已有序，后续轮次照样机械执行。就像整理书架，书按作者排好了，还要硬着头皮把整面墙再摸一遍，纯属空耗性能。

引入交换标记是最直接的止血手段。每轮开始前重置 swapped = false，只要发生位置互换就置为 true。本轮跑完检查标记，若全程为 false 说明区间已归位，直接跳出循环。这一步能让接近有序的数组从平方级直接拉回线性级，日常处理接口返回的局部重排列表时非常管用。

标记只能拦截“完全有序”的极端情况，面对头部混乱、尾部天然的半散乱数据，依然会在尾部做无用功。这时候必须上动态边界收缩。核心思路很朴素：记下本轮最后一次发生交换的下标，把它当作下一轮内层循环的天花板。为什么有效？因为最后一次交换点之后的元素，在本轮已经确认不再需要向前“冒”，它们天然处于正确相对位置。代码实现只需维护一个边界变量，内层遍历范围跟着收缩，未排查区域的扫描量呈几何级下降。

实际拼装时可以这样组织：

function optimizedBubble(arr) {
  const len = arr.length;
  let lastSwapIndex = len - 1;

  // **用边界值驱动循环，避免固定轮次死跑**
  while (lastSwapIndex > 0) {
    let currentSwapIdx = 0;

    // **内层只扫到上一次最终交换的位置**
    for (let j = 0; j < lastSwapIndex; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
        currentSwapIdx = j; // **实时更新最新活跃边界**
      }
    }
    // **下一轮直接截断已稳态的尾部**
    lastSwapIndex = currentSwapIdx;
  }
  return arr;
}

这段逻辑替换了传统的双重 for，改为 while 配合索引衰减，额外空间依然维持在常数级。拿 [5, 2, 8, 1, 3, 9, 10] 验证，第一趟会把 9 和 10 留在原地不参与内层判断，第二趟仅在 [5, 2, 8, 1, 3] 范围内震荡，边界肉眼可见地往里收。

很多人会纠结，优化到这种程度，生产环境能不能靠它扛活？坦白讲，V8 引擎内置的 Array.prototype.sort() 底层混合了快速排序与插入排序策略，经过多年底层指令集打磨，对常规数据集的碾压是结构性的。这套冒泡优化的真实落脚点在于特定微场景：本地缓存的小规模列表（通常不超过 50 项）、拖拽排序后的即时微调、或是需要严格保持稳定性的轻量工具函数。当你的数组天生带有序特征，或者只需要原地调整几根数据线，这套带边界追踪的写法既能守住内存底线，又不会触发 GC 压力。

算法从来不是背诵的标准件，而是顺着数据纹理做裁剪的手艺。把动态边界吃透，不仅能复活低效的冒泡，还能自然理解稳定排序为何在部分业务流里不可替代。下次再碰到底层需要就地修正数组顺序的需求，直接嵌进去用，省下的 CPU 周期正好留给首屏渲染和交互反馈。