微任务不阻塞渲染，但影响性能

微任务虽不直接阻塞渲染，但过度使用可能影响性能。本文深入剖析了微任务与渲染之间的微妙关系，揭示了微任务如何通过延迟渲染时机，导致页面卡顿和视觉不流畅。文章详细解读了JavaScript事件循环机制，阐述了微任务在宏任务之后、渲染之前的执行顺序，强调了长时间运行的微任务对用户体验的负面影响，如掉帧和不响应。针对这一问题，文章提出了三种优化策略：拆分任务、合理使用Promise以及将耗时任务移至Web Workers中执行。通过这些方法，开发者可以有效管理微任务，避免其长时间占用主线程，从而提升页面渲染效率，优化用户体验，让网页应用更加流畅。

微任务不会直接阻塞渲染，但会延迟渲染时机。因为微任务在当前宏任务执行后、渲染前执行，若微任务队列过长或执行复杂计算，将占用主线程，推迟浏览器更新屏幕的机会，导致页面卡顿。事件循环中，主线程执行完同步代码后优先处理所有微任务，之后才进行渲染和执行下一个宏任务。若微任务链过长，会持续推迟渲染，造成视觉上的不流畅。优化方式包括：1. 拆分任务，使用setTimeout或requestAnimationFrame分批执行；2. 合理使用Promise，避免嵌套与同步计算；3. 将耗时任务移至Web Workers中执行，释放主线程。

JavaScript中的微任务（microtasks）本身并不会“阻塞”渲染，至少不是我们通常理解的那种直接、粗暴的阻塞。它们运行在当前宏任务（macrotask）执行完毕之后，但在浏览器进行下一次渲染之前。这意味着，如果你的微任务队列里有大量计算或DOM操作，那么这些操作确实会延迟浏览器更新屏幕的机会，从而导致视觉上的卡顿或不响应。

解决方案

理解微任务与渲染的关系，关键在于把握JavaScript的事件循环机制。当浏览器执行一段JavaScript代码时，它会经历一个循环：首先执行主线程上的同步代码，然后处理微任务队列中的所有任务，接着才有可能进行渲染更新（如果需要且到了渲染时机），最后才会从宏任务队列中取出一个新的任务来执行。

微任务，比如Promise的回调（.then(), .catch(), .finally()），MutationObserver的回调，或者queueMicrotask()调度的任务，它们优先级非常高。它们会在当前脚本执行结束后，立即被处理，而不是等待下一个事件循环周期。如果这个微任务队列变得很长，比如你有一个深层的Promise链，或者在微任务中又调度了新的微任务，那么浏览器就必须等待所有这些任务都执行完毕，才能腾出手来处理渲染更新。

所以，虽然微任务不会像同步脚本那样直接“冻结”页面，但它们确实会霸占主线程，推迟浏览器渲染新帧的机会。这意味着，如果你的页面需要频繁的视觉更新来保持流畅（比如动画），而你又在微任务中做了大量工作，用户就会感觉到页面“卡顿”或“掉帧”。

JavaScript事件循环与渲染机制：它们是如何协同工作的？

要搞清楚微任务和渲染的关系，我们得先聊聊JavaScript的事件循环（Event Loop）以及浏览器渲染的节奏。这就像一个精密的齿轮系统，每个部分都有自己的职责和运行顺序。

简单来说，当浏览器主线程空闲下来时，它会检查几个地方：首先是执行栈（Call Stack），这里跑的是你当前正在执行的同步代码。当执行栈清空后，它不会立刻去处理下一个宏任务（比如setTimeout的回调），而是会优先检查微任务队列。所有排队的微任务会一个接一个地被执行，直到队列清空。只有当微任务队列也空了，浏览器才会考虑去处理一些其他高优先级的事情，比如：有没有需要重新计算样式（Recalculate Style），有没有需要重新布局（Layout），以及最关键的——有没有需要重绘（Paint）和合成（Composite）来更新屏幕显示。完成这些渲染步骤后，它才会从宏任务队列中取出一个新的任务来执行，开启下一个循环。

所以，你看，渲染是插在“一个宏任务执行完毕 + 所有微任务执行完毕”这个间隙里的。这意味着，如果你在一个宏任务里，或者在一个微任务里又触发了大量的微任务，这些微任务会“插队”到渲染之前执行。这并不是说微任务本身导致了渲染的“阻塞”，而是说它们占据了本可以用于渲染的时间片，延迟了渲染的发生。

长时间运行的微任务对用户体验的影响有哪些？

长时间运行的微任务，对用户体验来说，简直就是“隐形杀手”。它不像同步脚本那样直接让页面完全失去响应，而是表现为一种“掉帧”或者“卡顿”的感觉。想象一下，你在一个网页上滑动，或者点击一个按钮后期待立即看到反馈，结果却发现动画不流畅，或者点击后页面迟迟没有变化。这就是微任务可能在背后“捣鬼”的迹象。

最典型的场景是：你通过Promise链处理大量数据，或者进行复杂的DOM操作。比如，你从服务器获取了一大批数据，然后用Promise.all来处理它们，每个Promise的回调里又进行了一些计算或者创建了大量的DOM元素。这些Promise的回调都是微任务。如果数据量巨大，或者计算复杂，那么这些微任务就会一个接一个地执行，耗费大量CPU时间。在这期间，浏览器根本没有机会去更新页面。

用户会看到什么？他们可能会看到页面在某个操作后“凝固”了几百毫秒甚至几秒，没有任何视觉反馈。动画会变得不连贯，或者干脆停滞。更糟糕的是，如果用户在这期间尝试进行其他交互（比如再次点击），这些事件可能根本无法被及时处理，因为主线程正忙于执行微任务。这种不响应的感觉，极大地损害了用户对网站或应用的信任感和满意度。

如何优化微任务的使用以避免渲染阻塞？

既然微任务可能成为性能瓶颈，那么优化它们的使用就显得尤为重要。核心思想是：不要让微任务队列变得过长，或者不要在微任务中做太多耗时的工作。

一种非常有效的策略是拆分任务。如果你知道某个操作会产生大量微任务，或者某个微任务本身会执行很长时间，考虑把它拆分成多个小块，并在每个小块之间给浏览器一个喘息的机会。你可以利用setTimeout(..., 0)（虽然它是宏任务，但能有效将任务推迟到下一个事件循环迭代，从而允许中间进行渲染）或者更高级的requestIdleCallback（在浏览器空闲时执行任务，对不紧急的任务非常友好）。

例如，如果你需要创建大量的DOM元素：

function createElementsInBatches(data, container) {
    let index = 0;
    const batchSize = 50; // 每次处理50个
    const total = data.length;

    function processBatch() {
        const start = index;
        const end = Math.min(index + batchSize, total);

        for (let i = start; i < end; i++) {
            const div = document.createElement('div');
            div.textContent = data[i];
            container.appendChild(div);
        }

        index = end;

        if (index < total) {
            // 使用requestAnimationFrame来调度下一批，确保在渲染前有机会更新
            // 或者使用setTimeout(..., 0)来将任务推迟到下一个事件循环迭代
            requestAnimationFrame(processBatch);
            // 或者 setTimeout(processBatch, 0);
        }
    }

    requestAnimationFrame(processBatch); // 首次调度
}

// 假设data是一个很大的数组
// createElementsInBatches(largeDataArray, document.getElementById('myContainer'));

这里我们用了requestAnimationFrame来调度下一批次的DOM操作，这确保了在每一批DOM操作之后，浏览器都有机会进行渲染，从而避免长时间的卡顿。

另一个重要的点是明智地使用Promise。虽然Promise非常方便，但深层嵌套或者在一个Promise链中进行大量同步计算会快速填充微任务队列。审视你的Promise链，看看是否有可以将计算结果缓存，或者将非关键的、耗时的操作推迟到更晚的时机。

对于真正CPU密集型的计算，比如图像处理、复杂的数据分析等，最佳实践是利用Web Workers。Web Workers在独立的线程中运行，不会阻塞主线程，因此你的页面可以保持完全的响应性。当计算完成后，结果会通过消息传递回主线程，你可以在主线程上更新UI。

总之，优化微任务并非要避免使用它们，而是要合理地管理它们。理解它们在事件循环中的位置，并采取策略来避免它们长时间霸占主线程，是提升用户体验的关键。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《微任务不阻塞渲染，但影响性能》文章吧，也可关注golang学习网公众号了解相关技术文章。