第4章 JavaScript事件循环机制：宏任务与微任务、事件队列、异步编程对UI事件的影响

说实话，很多前端开发者写了几年代码，却搞不清楚为什么 setTimeout 的回调不按预期执行，或者为什么 UI 会卡顿。我当年也踩过这个坑——有一次做实时数据看板，用户疯狂点击刷新按钮，结果页面直接白屏了。查了半天，才发现是事件循环的队列优先级搞错了。

这一章，我们就来彻底搞懂 JavaScript 的事件循环机制。你想想看，UI 事件本质上也是异步任务的一种，它们怎么排队、谁先执行、会不会阻塞渲染，这些都直接决定了你的界面响应速度。

4.1 单线程的 JavaScript 如何“同时”做多件事？

JavaScript 是单线程语言，这大家都知道。但浏览器却能同时处理点击、滚动、网络请求、动画渲染……这是怎么做到的？

答案就是事件循环（Event Loop）。它像一个调度员，负责把各种任务按规则排队，然后一个一个交给主线程执行。

我习惯把事件循环理解成一个三层调度模型：

1. 调用栈（Call Stack）：当前正在执行的代码。栈空时，事件循环才会去取下一个任务。
2. 任务队列（Task Queue）：存放宏任务的地方，比如 setTimeout、setInterval、I/O、UI 事件。
3. 微任务队列（Microtask Queue）：存放微任务的地方，比如 Promise.then、MutationObserver、queueMicrotask。

这三者的执行顺序，是事件循环最核心的规则。我们直接看一张图：

4.2 宏任务 vs 微任务：谁先执行？

这是面试高频题，也是实际开发中容易出 bug 的地方。我们先看一个经典例子：

console.log('1');

setTimeout(() => {
  console.log('2');
}, 0);

Promise.resolve().then(() => {
  console.log('3');
});

console.log('4');

// 输出顺序：1, 4, 3, 2

为什么会这样？

• console.log('1') 和 console.log('4') 是同步代码，直接执行。
• Promise.then 是微任务，在当前宏任务结束后、下一个宏任务开始前执行。
• setTimeout 是宏任务，即使延迟为 0，也要等到下一轮事件循环。

说白了，微任务就是插队王。每次宏任务执行完，事件循环都会把微任务队列清空干净，才去取下一个宏任务。

4.3 UI 事件属于哪种任务？

UI 事件（click、scroll、touch、keydown 等）属于宏任务。它们被浏览器放入宏任务队列，等待事件循环调度。

但这里有个关键点：UI 事件的回调执行时机，和渲染是交替进行的。浏览器会在两次宏任务之间，检查是否需要重新渲染（即执行 requestAnimationFrame 和样式计算、布局、绘制）。

4.4 异步编程对 UI 事件的影响

我们写 UI 事件处理时，经常需要做异步操作，比如发请求、读数据、更新状态。这些异步操作怎么安排，直接影响用户体验。

4.4.1 场景一：点击按钮后发请求

button.addEventListener('click', () => {
  // 宏任务开始
  showLoading();  // 同步更新 UI

  fetch('/api/data')
    .then(res => res.json())
    .then(data => {
      // 微任务：更新数据
      updateUI(data);
    });
  // 宏任务结束
});

这里有个陷阱：showLoading() 虽然执行了，但浏览器的渲染可能还没发生。因为当前宏任务结束后，会先清空微任务队列（包括 fetch 的 .then），然后才渲染。如果 fetch 是缓存命中、立即 resolve 的，那么 updateUI(data) 会在同一个事件循环里执行，用户根本看不到 loading 状态。

button.addEventListener('click', () => {
  showLoading();
  // 强制渲染
  requestAnimationFrame(() => {
    fetch('/api/data').then(data => updateUI(data));
  });
});

4.4.2 场景二：连续点击导致重复请求

用户可能快速点击按钮多次，每次点击都会触发一个宏任务。如果每个宏任务都发请求，后端扛不住，前端也会因为频繁更新 UI 而卡顿。

我遇到过最夸张的一次，用户连点 20 次，页面直接崩溃。后来我用防抖（debounce）解决了：

let timer = null;
button.addEventListener('click', () => {
  clearTimeout(timer);
  timer = setTimeout(() => {
    // 只有最后一次点击才会执行
    fetch('/api/data').then(data => updateUI(data));
  }, 300);
});

防抖的本质，就是利用 setTimeout 把宏任务推迟，如果新的点击来了，就把上一个宏任务取消掉。

4.4.3 场景三：微任务阻塞 UI 渲染

假设你在 UI 事件回调里用 Promise 链做了大量计算：

button.addEventListener('click', () => {
  Promise.resolve()
    .then(() => heavyComputation1())
    .then(() => heavyComputation2())
    .then(() => heavyComputation3())
    .then(() => updateUI(result));
});

这些 .then 都是微任务，会在当前宏任务结束后连续执行。如果计算量很大，浏览器就没机会渲染，用户会感觉点击后界面“卡住”了。

4.5 实战：用事件循环优化 UI 响应

理解了原理，我们来看一个实际优化案例。假设有一个搜索框，用户输入时实时显示建议列表：

// 不好的写法：每次输入都立即执行
input.addEventListener('input', (e) => {
  const keyword = e.target.value;
  const results = filterData(keyword);  // 可能很慢
  renderSuggestions(results);
});

如果 filterData 很慢，每次输入都会阻塞 UI。优化方案：

1. 防抖：减少执行次数。
2. 把计算放到微任务或宏任务：避免阻塞渲染。
3. 使用 requestAnimationFrame：与渲染帧同步。

let timer = null;
input.addEventListener('input', (e) => {
  clearTimeout(timer);
  timer = setTimeout(() => {
    const keyword = e.target.value;
    // 用微任务执行计算，但注意不要太多
    Promise.resolve().then(() => {
      const results = filterData(keyword);
      // 用 requestAnimationFrame 更新 UI，与渲染同步
      requestAnimationFrame(() => {
        renderSuggestions(results);
      });
    });
  }, 200);
});

这样，输入事件是宏任务，计算放在微任务里，UI 更新放在 requestAnimationFrame 里，渲染就不会被阻塞。