UI渲染是事件循环的固定环节，发生在宏任务执行完毕且所有微任务清空后，由引擎主动触发；JS执行与GUI渲染互斥，需通过拆分任务、使用Web Worker或微任务边界来交还控制权。
UI 渲染和异步任务在事件循环中不是并列竞争的关系，而是被精心编排的协作流程——渲染本身就是一个宏任务阶段，且必须让位于微任务执行，但又不能被 JavaScript 长期霸占。
渲染是事件循环的固定环节，不是可选操作
浏览器不会“自动渲染”，而是在每次宏任务执行完毕、所有微任务清空后，主动触发一次渲染检查。这个时机由引擎控制，通常发生在：
- 一个宏任务（如 setTimeout 回调、用户点击事件）执行完
- 紧接着同步执行完所有已排队的微任务（Promise.then、MutationObserver）
- 然后判断 DOM 是否有变更、样式是否更新、布局是否需重算——若有，才真正进行重绘（Repaint）或回流（Reflow）
JS 执行会直接暂停 UI 更新
因为 JS 引擎线程与 GUI 渲染线程互斥：只要主线程在跑 JS（哪怕只是个空 while 循环），渲染线程就无法介入。这不是“优先级低”，而是硬件级互斥。常见表现包括：
- 修改 className 或 innerHTML 后，界面不立即变化
- 连续 setAttribute 多次，最终只看到最后一次效果
- 长耗时计算期间，按钮按下去没反馈、滚动卡顿、动画停顿
打破阻塞的关键是“交还控制权”
主线程不能靠“更快地跑完”，而要主动让出时间片，给渲染和其他任务机会。有效做法有：
- 拆分长任务：用 setTimeout 或 requestIdleCallback 把大循环切成小块，每执行几百次就暂停，让出主线程
- 移出主线程：将密集计算交给 Web Worker，主线程只负责通信和结果应用
- 善用微任务边界：比如在 Promise.then 里更新 DOM，能确保它在当前宏任务末尾、渲染前执行，比 setTimeout 更及时
- 避免强制同步布局：读取 offsetHeight/clientWidth 等会触发回流，若在循环中反复读写，会放大阻塞效应
浏览器其实有隐式调度策略
现代浏览器会根据任务类型分配队列，例如：
- 用户交互（click、input）进高优先级交互队列，尽可能快响应
- 定时器（setTimeout）进延时队列，精度受主线程负载影响
- 网络回调（fetch.then）和 Promise 进微队列，总在宏任务后立刻执行
- requestAnimationFrame 在下一次渲染帧前执行，天然对齐渲染节奏
这些机制共同保障了即使有异步任务排队，UI 也不会完全“失联”。关键在于开发者别用同步方式把主线程锁死。
