移动端中连续setTimeout为何无法独立运行并回调后更新UI？

这个问题本质上和JavaScript的事件循环机制以及移动端浏览器的性能优化策略有关，咱们一步步拆解清楚：

核心原因分析 #

1. 宏任务队列的批量处理 #

你写的代码里，for循环一下子创建了25000个setTimeout回调——要知道，setTimeout属于宏任务，所有宏任务都会被放进浏览器的任务队列里排队。浏览器会先把当前的同步代码（也就是整个for循环）执行完，才会开始逐个处理队列里的回调。

而且哪怕你设置了0延迟，浏览器也有最小执行间隔（不同浏览器不同，移动端为了省电可能会把这个间隔调得更高），这就导致这25000个回调会被批量塞进队列，然后连续执行，根本没有给UI更新留出空隙。

2. UI更新的时机限制 #

浏览器的UI重绘是有固定时机的：它只会在当前宏任务队列清空后，才会进行一次UI更新。也就是说，哪怕你在每个setTimeout回调里都修改了按钮文本，浏览器也不会立刻刷新界面，而是要等所有25000个回调都执行完，才会一次性把最后的结果渲染出来——这就是你看不到中间百分比变化的原因。

3. 移动端的额外优化 #

移动端浏览器为了节省电量和性能，会对高频的宏任务做合并处理。比如多个0延迟的setTimeout可能会被合并成一批执行，进一步压缩了UI更新的机会，让“不更新”的现象更明显。

解决方案：让UI更新跟上节奏 #

要解决这个问题，咱们需要让每个更新操作都和浏览器的重绘周期同步，或者给事件循环留出处理UI的时间，这里有两个常用方案：

方案1：使用requestAnimationFrame #

requestAnimationFrame是专门为UI动画/更新设计的API，它会在浏览器下一次重绘前执行回调，完美契合UI更新的时机。修改后的代码如下：

$(document).ready(function () {
  var $button = $('button');
  $button.on('click', function () {
    const total = 25000;
    let current = 1;

    function updateProgress() {
      if (current > total) {
        $button.text('Simulate');
        return;
      }
      // 更新进度
      $button.text((current / 250).toFixed(0) + '%');
      current++;
      // 在下一次重绘前继续执行
      requestAnimationFrame(updateProgress);
    }

    // 启动更新流程
    requestAnimationFrame(updateProgress);
  });
});

方案2：用async/await拆分任务 #

通过async/await配合Promise，把每个更新拆成独立的异步任务，让事件循环有机会在任务间隙处理UI更新：

$(document).ready(function () {
  var $button = $('button');
  $button.on('click', async function () {
    const total = 25000;
    for (let i = 1; i <= total; i++) {
      // 等待一个最小延迟，让浏览器处理UI
      await new Promise(resolve => setTimeout(resolve, 0));
      $button.text((i / 250).toFixed(0) + '%');
    }
    $button.text('Simulate');
  });
});

这两种方案都能让你在移动端看到按钮文本的实时更新，核心就是给浏览器留出了UI重绘的时间，而不是一次性塞进去大量任务。

内容的提问来源于stack exchange，提问作者Adam Zerner