微任务总在渲染帧之前执行完毕，dom修改虽可发生但不立即绘制；promise.then中修改dom不生效因需等宏任务结束且微任务清空后才进入渲染流水线。
微任务不是“总在渲染帧里修改 DOM”，而是总在渲染帧之前执行完毕——DOM 修改可以发生在微任务中，但浏览器不会立即绘制；你看到的“DOM 变了却没更新画面”，正是这个机制在起作用。
为什么 Promise.then 里的 DOM 修改不马上生效
因为 Promise.then 回调属于微任务，它被推入微任务队列后，必须等当前宏任务（比如一个 click 事件处理函数）执行完、所有微任务清空后，浏览器才进入渲染阶段。哪怕你在 then 里改了 innerHTML 或 style.color，这些变更只是写入了 DOM 树，还没走样式计算 → 布局 → 绘制 → 合成这一整套渲染流水线。
- 常见错误现象：在
button.addEventListener('click', () => { el.textContent = 'loading'; Promise.resolve().then(() => el.textContent = 'done'); })中，用户看不到 'loading' 文本闪现 - 原因不是 JS 慢，而是 'loading' 写入后还没渲染，就被 'done' 覆盖了；整个过程都在一次宏任务+微任务周期内完成，渲染只发生一次（在微任务清空之后）
- 若真想让用户看到中间态，得把 'loading' 改写放在宏任务里（如
setTimeout(() => el.textContent = 'loading', 0)），或强制触发一次渲染（见下一条）
如何让 DOM 修改在微任务后立刻可见
不能靠加更多微任务，得主动交出控制权给渲染引擎。唯一可靠方式是使用 requestAnimationFrame，它被设计为在下一帧绘制前执行，且位于微任务之后、渲染之前。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
requestAnimationFrame不是微任务，也不是宏任务，它是渲染管线中的一个特殊钩子，浏览器保证它在样式计算和布局之后、绘制之前运行 - 正确写法：
el.textContent = 'loading'; queueMicrotask(() => { /* 异步逻辑 */ }); requestAnimationFrame(() => { /* 这里能读到真实 layout 尺寸 */ }); - 注意：不要用
setTimeout(..., 0)模拟，它进的是宏任务队列，可能被其他宏任务（如另一个setTimeout或事件）插队，时序不可控
MutationObserver 是微任务，但它不保证渲染时机
MutationObserver 的回调确实是微任务，但它只保证「DOM 变更已被应用」，不保证「浏览器已完成样式/布局/绘制」。它常被误用于等待渲染完成，这是典型误用。
- 例如：
const mo = new MutationObserver(() => console.log('DOM changed')); mo.observe(el, { childList: true }); el.appendChild(span);—— 这个回调会在微任务阶段触发，但此时span的offsetHeight可能还是 0（未布局） - 真正需要测量尺寸时，必须搭配
requestAnimationFrame：mo.observe(el, { childList: true }); el.appendChild(span); requestAnimationFrame(() => console.log(span.offsetHeight)); - 性能影响：频繁触发
MutationObserver会堆积大量微任务，拖慢主线程响应；应限制观察范围，或用queueMicrotask批量合并变更
最易被忽略的一点：微任务清空是同步、不可中断的。只要有一个 Promise.then 里递归调用 queueMicrotask，就能阻塞渲染长达数毫秒——这比一个长同步函数更隐蔽，因为堆栈里全是“合法”的异步调用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
