dom变动后ui不立即更新，是因为浏览器采用渲染帧节流机制，将多次变更攒至下一帧统一处理，避免频繁触发layout→paint→composite；同步操作如读取offsetheight会强制刷新队列引发回流，而transform、opacity等仅触发重绘或合成。
交互反馈不是“加个class再改个颜色”就完事——DOM变动和UI渲染之间隔着完整的渲染流水线，中间任何一环卡住，用户就会感知到延迟或卡顿。
DOM变动后为什么UI没立刻更新？
浏览器不会在每次 innerHTML、classList.add() 或 style.color = 'red' 后马上重绘。它会把多个变更攒在一起，在下一个渲染帧统一处理。这个机制叫“渲染帧节流”，本质是避免高频操作反复触发 layout → paint → composite 流程。
- 同步 DOM 操作（如
el.style.width = '200px'）可能立即触发 layout 计算，但不保证画面更新 - 读取布局属性（如
el.offsetHeight）会强制 flush 队列，提前触发回流，反而拖慢后续操作 - 连续 5 次
appendChild不如一次用DocumentFragment批量插入——后者只触发 1 次回流
哪些 DOM 变动会触发回流？哪些只重绘？
关键看是否影响几何信息：只要改变元素的尺寸、位置、结构，就触发回流；只改颜色、透明度、阴影等不影响布局的属性，只重绘。
- 触发回流的操作：
offsetWidth、getBoundingClientRect()、修改width/height、top/left（非 transform）、增删节点 - 只触发重绘的操作：
color、background-color、visibility、opacity（注意：opacity 改变不回流，但需 GPU 层合成） - 完全不触发重绘/回流的操作：
transform、will-change（前提是该元素已启用硬件加速层）
如何让反馈更及时、更可控？
不能依赖“改完就看到”，得主动介入渲染时机。浏览器提供 requestAnimationFrame 作为最贴近渲染帧的钩子，比 setTimeout 更精准。
- 把 UI 更新逻辑放在
requestAnimationFrame回调里，确保它跑在下一帧的 layout 阶段之前 - 如果要等 layout 完成再读取尺寸，用
requestAnimationFrame套一层，再加一次requestAnimationFrame（双 rAF） - 对频繁交互（如拖拽、滚动），用
debounce或throttle控制 DOM 修改频率，但别 debounce 到用户明显感知延迟的程度 - 动画类反馈优先用 CSS
transition或@keyframes，它们由合成器线程驱动，不走主线程 layout/paint
真正难的不是知道“该用 transform”，而是判断什么时候该放弃 JS 控制、交给 CSS；什么时候必须手动 flush layout；以及为什么用户点了按钮，300ms 后才看到 loading 动画——那多半是因为你刚执行了 el.offsetWidth，又紧接着改了 display。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
