微任务总是在ui渲染前被彻底清空，即宏任务结束后立即连续执行所有微任务直至队列为空，然后才进行ui渲染；这是html标准规定的强制流程，非引擎优化，确保状态更新与视图反馈时序稳定。
微任务总是在 UI 渲染开始前被彻底清空，这不是可选行为，而是浏览器渲染管线的硬性阶段顺序。
微任务清空发生在“宏任务结束之后、渲染开始之前”
每次一个宏任务（比如 script 整体执行、setTimeout 回调、用户点击事件）运行完毕，JS 引擎会立刻检查微任务队列，并连续执行其中所有任务，直到队列为空。这个过程不中断、不穿插其他操作，完成后才进入下一环节——UI 渲染。
- 同步代码属于第一个宏任务，它执行完就触发微任务清空
- 新产生的微任务（例如在 Promise.then 里再调用 Promise.resolve().then()）也会被追加到当前微任务队列尾部，并在本轮继续执行
- 即使微任务里又创建了新的微任务，只要队列没空，就一直执行下去
UI 渲染不会“抢在”微任务之前发生
浏览器不会因为等待渲染而跳过微任务。哪怕只有一行 console.log 和一个 Promise.resolve().then()，控制台输出也一定先于任何视觉变化出现。这是因为 DOM 更新逻辑（如 innerHTML 修改）虽然同步写入，但真实绘制必须等微任务全部跑完。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- MutationObserver 是微任务，它能捕获 DOM 变更并立即响应，正是因为它在渲染前执行
- 如果想让某个操作“在渲染后”执行，不能靠微任务，得用 requestAnimationFrame 或下一个宏任务（如 setTimeout(fn, 0)）
这不是 JS 引擎的优化，而是规范强制要求
该流程由 HTML 标准明确定义：宏任务 → 微任务（全部）→ 渲染 → 下一个宏任务。它不是 V8 或其他引擎的实现细节，所有现代浏览器都遵守这一铁律。目的是确保开发者对状态更新和视图反馈的时序有稳定预期。
- 比如表单提交后立即禁用按钮，再发请求，用户不会看到按钮闪烁一下又恢复
- 所有异步状态变更（Promise 链、Observer 回调）都会聚合到一次渲染前完成，避免中间态暴露
常见误解澄清
有人以为“微任务快所以先执行”，其实关键不在快慢，而在阶段不可跳过。即使把 setTimeout 延迟设为 1ms，它依然排在所有微任务之后；哪怕页面静止不动，没有重绘需求，微任务仍会在渲染检查环节前被执行——只是渲染步骤被跳过而已。
- 微任务不是“比宏任务早一点”，而是“卡在宏任务和渲染之间那个固定位置”
- queueMicrotask() 的作用就是手动插入一个标准微任务，时机与其他微任务完全一致
- UI 渲染本身是宏任务的一种，但它由浏览器自动调度，不进入 JS 可见的任务队列
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
