Vue响应式系统触发的是局部更新而非全量更新，通过细粒度依赖追踪精准通知相关组件重新渲染并执行vnode diff与patch。
Vue.js 的响应式系统并不会触发虚拟 DOM 树的“全量更新”，这是一个常见误解。真正发生的是：当响应式数据变化时，Vue 会精准通知依赖该数据的组件或计算属性重新求值，进而触发对应组件子树的 vnode diff 和 patch——即局部更新。所谓“全量更新”通常源于不当使用或设计，而非响应式机制本身。
响应式追踪是细粒度的，不是全局广播
Vue 2 使用 Object.defineProperty，Vue 3 使用 Proxy，都实现了对属性读取（getter）和修改（setter）的拦截。在组件 render 过程中，被访问的数据属性会自动收集为当前组件的依赖；后续该属性变化时，仅通知这个组件重新执行 render 函数，生成新的 vnode，再与旧 vnode 做对比（diff）。整个过程天然限定在组件作用域内。
例如：
- 一个深层嵌套对象的某个字段变化，只会影响读取了该字段的组件，不会波及其他无关组件
- 多个组件各自读取同一响应式对象的不同字段，它们的更新彼此独立、互不干扰
哪些情况会“看起来像全量更新”？
实际性能问题往往来自以下几种误用模式：
立即学习“前端免费学习笔记（深入）”；
-
把大量无关状态塞进同一个响应式对象：比如将整个后端返回的巨型 JSON 直接赋给
data或ref，哪怕只改其中一两个字段，所有用到该对象的组件都会重新 render（因为 Vue 默认对对象做浅层依赖收集，但 render 中若展开访问了整个对象，就会建立强依赖） -
滥用
v-for且未提供稳定key：导致 diff 算法无法复用节点，每次更新都销毁重建整组 DOM，视觉上类似“重绘全部” - 在 render 函数或模板中执行高开销操作：如遍历大数组、调用未缓存的复杂计算函数，会使单次更新耗时剧增，拖慢整体响应
-
父组件响应式数据频繁变更，且子组件未合理使用
shouldUpdate或memo（Vue 3 的shallowRef/markRaw）：导致子组件被动跟随更新，即使其 props 实际未变
优化关键：控制依赖范围 + 提升 diff 效率
根本思路不是“避免响应式”，而是让依赖更精准、diff 更轻量：
- 拆分大型响应式对象，按业务域划分
ref或store modules，确保组件只订阅真正需要的字段 - 对只读的大数据结构（如列表项原始数据），用
markRaw跳过响应式转换，改用事件/状态管理显式触发更新 - 在
v-for中始终使用有意义的唯一key，避免用index - 用
computed缓存派生状态，避免模板中重复计算；对静态内容考虑用v-once - 必要时用
shallowRef或shallowReactive控制响应深度，防止深层属性意外触发更新
调试手段：定位真实瓶颈点
不要凭感觉判断“是不是全量更新”。推荐组合使用：
- Vue Devtools 的 Performance 标签页：录制操作，查看哪些组件 re-render、耗时分布、vnode diff 次数
- 在组件
beforeUpdate钩子打日志，确认是否被意外触发 - 用
watch监听特定响应式变量，验证变更是否符合预期频率和来源 - Chrome DevTools 的 Performance Recorder 分析 JS 执行栈，区分是响应式开销、render 耗时还是 patch 成本高
响应式系统本身设计精巧，性能瓶颈几乎总是出在数据建模、组件划分或更新策略上，而不是响应式机制的固有缺陷。理解依赖收集的边界、掌握 diff 的前提条件、善用调试工具，才能真正解决“卡顿”问题。
