微任务总在当前宏任务结束、渲染开始前清空完毕；执行顺序为：宏任务→微任务队列清空→requestanimationframe→layout/paint→下一宏任务。

微任务在页面渲染前触发，但绝不会在渲染“过程中”或“之后”才执行——它总是在当前宏任务结束、渲染开始前清空完毕。

微任务严格位于渲染之前

浏览器的事件循环中，每次完成一个宏任务（比如一段 script、一次 click 回调），主线程会立即转入微任务处理阶段：逐个执行 Promise.then、queueMicrotask、MutationObserver 回调，直到微任务队列完全为空。这个过程发生在 UI 渲染（layout/paint）之前，且不中断、不暂停。也就是说，哪怕你连续添加 100 个 queueMicrotask，它们也会一口气执行完，渲染才会启动。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• DOM 修改后立即加 Promise.then → 回调里能读到最新 DOM 状态，但用户还看不到变化（因为还没渲染）
• 在 microtask 中再次修改 DOM → 不会触发额外渲染，仍等本次循环末尾统一绘制
• 若微任务中抛错未捕获，会阻断后续微任务执行，但不影响已排队的渲染时机

渲染不是微任务的“后置环节”，而是它的“下一站”

微任务和渲染之间没有中间层。执行顺序固定为：宏任务结束 → 微任务队列清空 → requestAnimationFrame（如果存在且时机合适）→ 浏览器 layout + paint → 下一个宏任务。rAF 回调虽常被误认为“渲染后”，实则运行在渲染前的帧准备阶段，优先级低于微任务但高于宏任务。

• rAF 不是微任务，也不属于宏任务，它是独立的“帧回调”，在微任务之后、渲染之前执行
• 没有“渲染后微任务”这种机制；想响应渲染完成，得用 MutationObserver（监听 DOM 变更）或 requestAnimationFrame + setTimeout 组合模拟
• 强制同步渲染（如 offsetHeight 触发重排）不影响微任务调度逻辑，只增加计算开销

常见误解澄清

很多人以为“DOM 更新了，Promise.then 就该在渲染后执行”，这是把 JS 执行和视觉反馈混为一谈。实际上：

• DOM 属性/结构变更只是内存操作，不等于画面刷新
• 微任务里的代码能读写 DOM，但所有变更都积压到本轮循环末尾统一渲染
• setTimeout(fn, 0) 总是比 Promise.then 晚一轮，因为它进的是宏任务队列，要等渲染完成才能取

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南