事件循环与浏览器渲染共享主线程、协同工作：每轮事件循环执行一个宏任务后清空微任务队列，再检查并触发渲染；requestanimationframe在渲染前执行，ui渲染本身属宏任务级操作。
JavaScript 的事件循环（Event Loop）和浏览器渲染不是两个独立过程，而是被同一个调度机制紧密协同的——每次事件循环迭代结束时，浏览器会主动检查是否需要更新画面，这个时机就是渲染发生的“窗口”。
渲染发生在微任务清空之后、下一个宏任务开始之前
浏览器在每轮事件循环中执行顺序是： → 执行一个宏任务（如 script 主体、setTimeout 回调） → 立即执行所有已排队的微任务（Promise.then、MutationObserver、queueMicrotask） → 此时 DOM 可能已被修改，但尚未绘制 → 浏览器判断是否需要渲染：若存在未提交的样式变更、DOM 变动或动画帧请求，就触发一次渲染（paint + composite） → 进入下一轮宏任务
这意味着：你在 Promise 回调里改了元素颜色，用户不会立刻看到；要等到这轮微任务全部跑完、渲染阶段到来，变化才真正出现在屏幕上。
requestAnimationFrame 是渲染前的最后一道“钩子”
requestAnimationFrame(callback) 注册的回调，会在下一次浏览器重绘前执行，且仅执行一次。它不进微任务队列，也不进宏任务队列，而是由浏览器在渲染阶段开始前主动调用。
常见用途包括： • 同步动画逻辑与屏幕刷新率（通常是 60fps） • 在 DOM 更新后、渲染前读取布局（避免 layout thrashing） • 替代 setTimeout(…, 0) 做更精准的视觉同步
例如：
document.body.style.transform = 'translateX(100px)';
requestAnimationFrame(() => {
console.log(getComputedStyle(document.body).transform); // 拿到刚设的值
});
UI 渲染本身是一个宏任务级操作
在 HTML 规范中，UI rendering 被明确列为一种宏任务（尽管没有显式放入队列）。它和其他宏任务（如 setTimeout）共享调度优先级，但浏览器会按需插入——不是每轮都渲染，而是当检测到视觉状态可能变化时才触发。
哪些情况会触发渲染？ • DOM 结构或样式发生变更（且未被后续操作覆盖） • 页面处于前台、未被冻结（如标签页失焦时渲染可能暂停） • 有 pending 的 requestAnimationFrame 回调 • 用户交互（如 scroll、resize）产生视觉反馈需求
注意：连续快速修改 DOM 不会逐次渲染，浏览器会合并变更，在下一个渲染帧统一处理。
实际开发中要注意的协调点
理解 Event Loop 与渲染的配合，能帮你避开常见陷阱： • 不要在微任务里反复修改同一 DOM 属性（如循环 setAttribute），因为渲染只在最后发生一次，中间操作白费 • 需要“立即看到效果”？可用 force reflow（如读 offsetHeight），但这会强制同步渲染，影响性能 • 使用 Vue.nextTick 或 React.useEffect 的时机，本质都是借用了微任务队列，在渲染前确保 DOM 已更新 • MutationObserver 回调属于微任务，适合做轻量 DOM 响应；而 resize 或 scroll 事件是宏任务，响应稍慢但更稳定
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
