ui重绘发生在宏任务结束、微任务队列清空后且下一宏任务开始前的固定节点；它不随dom修改即时触发，也不等“下一帧”，而是由事件循环严格调度，需用requestanimationframe确保读取最新渲染结果。
UI 重绘不是随时发生的，而是在事件循环中一个明确、固定的插入点触发的：它发生在当前宏任务执行完毕、微任务队列被彻底清空之后，且在下一个宏任务开始之前。
重绘时机由事件循环严格控制
浏览器不会在每次 DOM 修改后立即渲染，也不会等到“下一帧”再统一处理。它把渲染当作一个隐式的、高优先级的宏任务，但不放入宏任务队列排队，而是硬性安排在以下节点：
- 上一个宏任务（如点击事件回调、setTimeout 回调）已完全执行结束
- 所有已排队的微任务（Promise.then、queueMicrotask、MutationObserver 回调）已被逐个执行，直到队列为空
- 此时浏览器检查 DOM 是否发生变更、样式是否更新、布局是否受影响
- 若需更新，立刻触发重排（reflow）和重绘（repaint），否则跳过
为什么不能依赖“修改完就可见”
开发者常误以为 element.style.color = 'red' 后界面马上变色，实际并非如此。同步代码执行完、甚至 Promise.then 里改完 DOM，仍处于“渲染前状态”。例如：
- 直接读取
offsetHeight或getBoundingClientRect()可能拿到旧值 - 连续多次 DOM 写操作会被合并，但读操作若插在中间，会强制同步计算布局（layout thrashing）
- 想确保读到最新渲染结果，得等重绘完成——但 JS 无法直接监听“渲染结束”，只能借助
requestAnimationFrame
如何主动对齐重绘节奏
虽然不能干预渲染本身，但可通过任务调度让逻辑落在合适位置：
- 需要“DOM 更新后立刻响应”，用
Promise.resolve().then()—— 它在微任务阶段执行，确保 DOM 已更新但尚未渲染 - 需要“渲染完成后执行”，用
requestAnimationFrame(() => {...})—— 浏览器保证回调在下一帧绘制前调用 - 避免长任务阻塞主线程：单次宏任务运行超过 16.6ms（即一帧时长），就会跳过当次渲染，导致掉帧
宏任务与渲染不是一一对应
不是每个宏任务都会触发重绘。只有当该宏任务及其后续微任务导致了影响视觉的变更（如 DOM 结构变化、CSSOM 更新、媒体查询匹配改变等），浏览器才会安排重绘。空操作或仅修改不影响样式的属性（如 dataset）不会触发渲染。
