虚拟 DOM 触发频率取决于组件对变更数据的依赖关系而非变更次数，响应式系统细粒度追踪字段级访问，配合异步更新队列合并同批变更，确保单次 tick 中每个组件仅 render 一次；高频变更不会导致高频 VDOM 更新，真正影响频次的是状态设计粗放、key 不稳定或更新边界失控。
虚拟 DOM 的触发频率不取决于响应式系统“变了多少次”，而取决于哪些组件的渲染函数实际读取了变更的数据，以及这些组件是否被标记为需要重新渲染。
触发不是按数据变更次数，而是按依赖关系
Vue 的响应式系统是细粒度的。一个 ref 或 reactive 对象的某个字段变化，只会影响 明确访问过该字段 的组件或计算属性。比如：
- 组件 A 的模板中用了
{{ user.name }}→ 只有user.name变，A 才会 re-render - 组件 B 用了
{{ user }}（整个对象）→user任意字段变，B 都会 re-render - 组件 C 根本没用到
user→ 即使user.age改一百次，C 也完全不动
高频变更 ≠ 高频虚拟 DOM 触发
即使用户快速输入、滚动或拖拽，导致某个 ref 每秒更新 50 次，虚拟 DOM 也不会跟着跑 50 次。因为：
- Vue 把所有同一批变更合并进一个异步更新队列
- 同一组件在单次 tick 中多次被标记为“待更新”，最终只执行一次 render 函数
- render 函数执行后生成新 VNode，才进入 diff 流程 —— 这个环节只发生一次/组件/轮次
真正拉高虚拟 DOM 触发频次的常见原因
不是响应式本身太勤快，而是代码设计放大了触发范围：
立即学习“前端免费学习笔记（深入）”；
- 把大对象整个赋给一个 ref（如
data = response.data），然后模板里直接展开用，导致任意子字段变都触发整块视图重算 -
v-for列表没设稳定key，每次更新都让 diff 算法放弃复用，看起来像“全量重绘” - 父组件响应式数据频繁变动，子组件又没用
shallowRef、markRaw或shouldUpdate控制更新边界 - 在
watch或事件回调里同步读写 DOM（如el.offsetHeight），触发强制同步布局，间接拖慢后续虚拟 DOM 执行节奏
控制虚拟 DOM 实际触发次数的关键动作
与其减少响应式变更，不如让变更“影响更少”：
- 拆分状态：用多个细粒度 ref 替代一个巨型 reactive 对象
- 跳过劫持：对只读大数据（如表格原始行数据）用
markRaw()，改用事件或状态管理显式通知视图 - 稳定 key：v-for 必须用业务唯一 ID，不用
:key="index" - 缓存派生：复杂计算放
computed，避免模板里重复调用；静态内容加v-once - 浅层响应：深层嵌套结构若只需顶层响应，用
shallowRef或shallowReactive
