事件循环直接决定UI渲染时机，每轮循环按“宏任务→微任务→渲染检查点”顺序执行；DOM修改仅更新内存状态，需等到渲染检查点才统一绘制，故不立即生效。
事件循环直接决定 UI 渲染何时发生——它不是独立运行的，而是嵌入在事件循环的固定阶段中。浏览器不会随时渲染，而是在每轮事件循环结束时，检查是否需要更新界面，再执行渲染。
UI 渲染是事件循环的“收尾环节”
每轮事件循环严格按顺序推进：
- 先执行一个宏任务（比如点击回调、setTimeout 回调、初始脚本）
- 宏任务结束后，调用栈清空，立即执行所有排队的微任务（Promise.then、MutationObserver 回调等），直到微任务队列为空
- 微任务全部执行完毕后，浏览器才进入“渲染检查点”：判断 DOM/CSS 是否变化、布局是否需重算、是否有动画帧待绘制
- 若判定需要更新，就同步完成样式计算、布局（Layout）、绘制（Paint）、合成（Composite）——这一整套过程即为一次 UI 渲染
为什么 DOM 修改后页面不立刻变？
因为你写的 element.style.color = 'red' 或 div.innerHTML = 'new' 只是改变了内存中的 DOM 状态，并不触发即时绘制。浏览器会把这类变更暂存，等到下一次渲染检查点统一处理。
- 即使连续修改 10 次 DOM，只要都在同一个宏任务或连续微任务中，最终也只触发一次渲染
- 想强制提前渲染？无法直接调用，但可用
requestAnimationFrame把逻辑安排在“下次渲染前”执行，常用于动画控制 - 调试时看到“马上生效”，往往是因为断点暂停打断了流程，让浏览器在恢复前插入了一次渲染检查
耗时操作如何干扰渲染？
主线程被长期占用，等于锁死了整个事件循环节奏：
- 一个运行 100ms 的同步函数，会阻塞后续所有宏任务、微任务，更关键的是——跳过至少 6 次渲染机会（因 60Hz 下每帧仅 16.6ms）
- 微任务虽快，但大量 Promise 链式调用（如未加节制的
Promise.resolve().then(...).then(...)）也会延后渲染，因为它必须等全部微任务跑完才进入渲染阶段 - 真正“不影响交互”的只有宏任务队列本身——用户点击仍能进队，只是得等当前长任务结束才能被处理
如何主动配合渲染节奏？
不强行干预，而是顺应事件循环设计：
- 用
requestAnimationFrame(callback)替代setTimeout(callback, 0)做动画更新，确保 callback 在下一帧绘制前执行 - 拆分长任务：每执行约 5ms 就用
setTimeout或queueMicrotask让出主线程，给渲染留出空隙 - 批量 DOM 操作尽量合并，避免在单次任务中反复触发样式/布局计算（如读 offsetHeight 后又改 class）
- 对非关键逻辑（如日志、统计上报），可降级到微任务（
queueMicrotask）而非宏任务，减少延迟感
