事件循环是dom渲染的调度中枢，决定浏览器何时可渲染；渲染本身由浏览器控制，在宏任务后检查是否需绘制，微任务总在渲染前执行完毕。
事件循环在 DOM 渲染中起调度中枢作用：它不直接渲染，而是决定“何时允许浏览器去渲染”。渲染本身由浏览器控制，但时机受事件循环阶段严格约束。
DOM 渲染是事件循环的一个可选阶段
浏览器标准（WHATWG HTML）规定，每次宏任务执行完毕后，事件循环会进入“渲染检查点”——但是否真正触发绘制，取决于是否有视觉变化、是否处于活跃标签页、是否被节流等。这个阶段不是强制渲染，而是浏览器判断“现在适合不适合画一帧”。
- 只有当 DOM 树或 CSSOM 发生变更，且浏览器判定需要更新画面时，才会走 layout → paint → composite 流程
- 若没有样式/结构变动，或页面被最小化、后台运行，该阶段可能跳过
- requestAnimationFrame 回调总是在本次渲染前执行，属于“渲染前钩子”，常用于动画帧同步
微任务总在渲染前执行完毕
这是关键约束：所有已入队的微任务（Promise.then、queueMicrotask、MutationObserver 回调）必须在浏览器考虑渲染前全部执行完。
- 例如：你在 Promise.then 里修改了元素 innerHTML，这个变更会立即反映在 DOM 树中，但用户还看不到——要等到接下来的渲染阶段才可能显示
- 如果连续触发多个 MutationObserver，它们会批量合并、统一响应，再一次性交由微任务队列执行，避免重复渲染
- 这保证了“一次 JS 执行 + 一次渲染”的原子性，防止界面出现中间态闪烁
宏任务与渲染的节奏绑定
每个宏任务（如 setTimeout 回调、事件处理函数、<script> 全局代码）执行完后，事件循环才会走到渲染检查点。</script>
- 这意味着：长任务（如耗时 100ms 的计算）会推迟渲染，造成卡顿；浏览器可能强制切分任务，或触发“长任务警告”
- UI Rendering 本身被归类为一个宏任务类型，但它不由 JS 主动调度，而是由浏览器在合适时机自动插入
- 使用 setTimeout(fn, 0) 或 postMessage 可把逻辑推到下一个宏任务，从而让出主线程、触发一次潜在渲染机会
实际开发中可干预的渲染时机
虽然不能强制渲染，但可以通过以下方式影响渲染节奏：
- 用 requestAnimationFrame 把 DOM 更新对齐到下一帧起点，比 setTimeout(0) 更精准
- 用 queueMicrotask 延迟到本轮微任务末尾执行轻量更新，避免打断当前流程
- 批量修改 DOM（如 documentFragment、innerHTML 一次性写入），减少 reflow/reflow 触发次数
- 避免在 scroll/touchmove 中同步修改样式，改用 rAF 节流 + class 切换
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
