浏览器渲染引擎与事件循环共享主线程、协同工作；渲染流水线（DOM/CSSOM构建、Layout、Paint、Composite）和JS执行均在主线程顺序进行，长同步JS会阻塞渲染；事件循环调度宏/微任务后触发隐式渲染检查，requestAnimationFrame在此窗口执行；强制同步读写操作（如offsetWidth、getComputedStyle）引发回流重绘，成为性能瓶颈；优化核心是主动让出控制权：拆分长任务、批量DOM操作、高频事件节流、非关键逻辑移至Web Worker。
浏览器渲染引擎和事件循环不是两个独立运转的系统，而是共享主线程、彼此制约又协同工作的搭档。理解它们的交互，关键在于抓住“谁在什么时候让出控制权”这个核心。
渲染引擎干的活，全在主线程上
从 HTML 解析构建 DOM 树，到加载 CSS 生成 CSSOM，再到合成渲染树、计算布局（Layout）、绘制图层（Paint）、最后合成显示（Composite）——整个渲染流水线都在渲染主线程中顺序执行。JS 脚本的执行、事件回调、定时器触发，也都挤在这同一条线上。
这意味着：一段耗时的 JS 同步代码（比如长循环或复杂计算）会一直占着主线程，渲染引擎就只能干等，页面就会卡住不动，哪怕你已经改了样式、加了元素，也看不到任何变化。
事件循环是调度员，但不直接管渲染
事件循环本身不执行渲染，它的职责是按序取出宏任务（如 setTimeout 回调、用户点击）、清空微任务队列（如 Promise.then），然后告诉主线程：“这一轮任务处理完了”。此时，浏览器才会主动检查：是否需要更新画面？
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
这个检查发生在每次宏任务 + 全部微任务执行完毕之后，是一个隐式的、由浏览器自动触发的步骤。它不是任务队列里的一个可排队项，而是一次“机会窗口”：
- 如果 DOM 或样式有变更，且浏览器判定该帧还没过期，就会走 Layout → Paint → Composite 流程
- 如果前一帧还没画完，或者主线程还在忙，这次渲染就可能被跳过或延迟
- requestAnimationFrame 的回调，就插在这个窗口里、渲染之前执行，所以它是最适合做动画更新的时机
读写操作会强制打断节奏
有些 DOM 操作看似简单，却会立刻触发同步计算，把渲染流程“拽”进当前执行流：
- 读取 offsetWidth、scrollTop、getComputedStyle() 等布局/样式信息时，浏览器必须立刻完成样式计算和布局，才能返回准确值
- 连续“读-写-读-写”，会导致多次强制回流（reflow），极大拖慢执行速度
- 这类操作与事件循环无关，也不等微任务，是同步阻塞行为，容易成为性能瓶颈
优化本质是“主动交还控制权”
真正影响用户体验的，从来不是事件循环多难懂，而是你有没有在关键节点松手：
- 把长任务拆成小块，中间用 setTimeout 或 queueMicrotask 让出主线程，给渲染留出时间
- 批量修改 DOM，避免反复触发重排重绘；用 documentFragment 或脱离文档流的方式操作
- 对 scroll/mousemove 等高频事件做节流或防抖，防止任务队列被瞬间塞爆
- 非关键逻辑移入 Web Worker，彻底解放主线程
