虚拟 DOM 通过智能比对和批量更新减少真实 DOM 操作，从而间接降低重排重绘次数；它依赖 key 精准复用节点、跳过无效更新，并需配合底层 DOM 优化习惯。
虚拟 DOM 本身不直接触发重排或重绘，它的价值在于减少真实 DOM 的修改频次和范围，从而间接压制重排（reflow）和重绘（repaint）的次数与开销。关键不是“虚拟 DOM 能避免重排”，而是它通过智能比对和批量更新，让浏览器只在必要时、以最简方式执行真实 DOM 操作。
用批处理压缩重排次数
真实 DOM 每次插入、删除或样式变更都可能触发重排；而虚拟 DOM 框架（如 AppRun、React、Snabbdom）会把同一帧内的多次状态变更收集起来，在一次更新周期内完成 diff 并生成最小补丁。这意味着 10 次状态变化 → 通常只对应 1 次真实 DOM 批量提交 → 最终仅引发 1 次重排（或更少）。
- AppRun 在
tests/vdom-my-batching-benchmark.spec.tsx中验证了该机制可将 100 次独立插入从 ~800ms 降至 ~150ms - 避免在事件回调中频繁 setState 或触发 rerender，可手动合并操作（例如使用防抖、节流，或 accumulate 后统一提交）
- 框架内部的 batch update 依赖于 event loop 阶段（如 React 的 concurrent mode 或 AppRun 的调度器），不建议自行用
setTimeout拆分更新，否则可能破坏批处理
键控列表（keyed lists）精准复用节点
渲染大型列表时，若不提供稳定唯一的 key，虚拟 DOM 只能按顺序逐项比对，容易误判为“全部新增/删除”，导致整列 DOM 重建——这会引发大面积重排。加上 key 后，框架能识别元素身份，只移动、复用、局部更新节点。
- key 必须是字符串，且在同一层级下唯一、稳定（不随排序或索引变化）
- 避免用
Math.random()或index作 key，尤其在动态增删或排序场景下 - 移动一个带 key 的列表项，虚拟 DOM 会生成
move指令，浏览器只需调整其位置（CSS transform 更优），而非删除再插入
跳过无意义更新，切断重排链路
并非所有状态变化都需要反映到 DOM。虚拟 DOM 的 diff 过程天然支持“跳过”：当新旧 vnode 完全一致（或标记为 shouldSkip），框架不会生成任何 DOM 操作，也就不会触发后续重排重绘。
- 合理使用
shouldComponentUpdate（类组件）或React.memo/useMemo（函数组件）避免无效渲染 - AppRun 提供的“跳过逻辑优化”可在 state 未实际影响视图时终止更新流程（资料日期：2026年3月15日）
- 对纯展示型组件，确保 props 是浅层不可变的；深层对象引用变化但内容未变时，也要主动做值比较，防止误触发
配合底层 DOM 优化习惯
虚拟 DOM 是上层策略，仍需尊重浏览器渲染机制。即使用了虚拟 DOM，不当的 DOM 访问或样式操作仍会强制同步重排。
- 避免在 render 函数或 effect 中读取
offsetWidth、getComputedStyle()等布局属性 - 动画优先用
transform和opacity，它们不触发重排，只走合成层（compositor） - 大量节点插入前，可用
DocumentFragment做兜底（例如 SSR 后 hydrate 阶段的手动挂载）
