在 Vue 3 组合式 API 下，组件重新渲染的频率直接影响页面流畅度。不少开发者把 ref 和 reactive 用得很顺手，但组件却莫名其妙地多渲染了几十次。问题通常不在写法本身，而在依赖追踪的颗粒度上。下面我从几个实际排查中常用的角度，说说怎么一步步收紧触发条件。

在组合式 API 中，`computed` 和 `watch` 的依赖列表决定了组件何时触发更新。一个常见误区是将所有用到的响应式变量全部放入依赖，导致无关数据变化引发重渲染。正确的做法是仅保留直接影响计算结果的变量，对于仅用于条件判断或辅助计算的临时变量，通过普通函数或 `toRaw` 剥离其响应式追踪。例如 `computed(() => flag ? rawObj.a : rawObj.b)` 中，若 flag 变化才需重新计算，而 `rawObj` 已用 `toRaw` 转为非响应式，可避免深层属性变动触发更新。

当组件只关心引用变化而非内部深层属性时，用 `shallowRef` 或 `shallowReactive` 替代默认深度响应式。比如列表项对象频繁局部更新但整体引用不变，使用 `shallowReactive` 后，修改对象内部属性不会触发视图渲染，只有替换整个对象才会。这在大数组或深层嵌套数据场景下能显著减少不必要的渲染。但需注意边界：如果组件模板直接使用了深层属性，必须手动调用 `triggerRef` 来通知更新，否则视图不会响应。

从依赖追踪开始收紧范围

在组合式 API 中，computed 和 watch 的依赖列表决定了组件何时触发更新。一个常见误区是将所有用到的响应式变量全部放入依赖，导致无关数据变化引发重渲染。正确的做法是仅保留直接影响计算结果的变量，对于仅用于条件判断或辅助计算的临时变量，通过普通函数或 toRaw 剥离其响应式追踪。例如 computed(() => flag ? rawObj.a : rawObj.b) 中，若 flag 变化才需重新计算，而 rawObj 已用 toRaw 转为非响应式，可避免深层属性变动触发更新。

这里的关键是：依赖列表里只放真正参与结果的变量。比如有一个商品列表，每个商品有价格和折扣，computed 计算折后价，依赖只有 price 和 discount，不要因为商品描述也用了 ref 就把整个对象放进去。如果需要在模板里展示其他字段，单独用 ref 或 computed 派生出来。验证方法很简单：在 computed 里加一行 console.count('computed triggered')，然后操作无关数据，观察计数是否增加。如果增加，说明依赖绑定宽了，用 toRaw 或拆分 ref 来处理。

用浅层响应式替代深度监听

当组件只关心引用变化而非内部深层属性时，用 shallowRef 或 shallowReactive 替代默认深度响应式。比如列表项对象频繁局部更新但整体引用不变，使用 shallowReactive 后，修改对象内部属性不会触发视图渲染，只有替换整个对象才会。这在大数组或深层嵌套数据场景下能显著减少不必要的渲染。但需注意边界：如果组件模板直接使用了深层属性，必须手动调用 triggerRef 来通知更新，否则视图不会响应。

举个实际场景：一个用户列表，每行有个“在线状态”每秒变化，但整个用户对象（头像、昵称等）引用不变。如果用 reactive，每秒都要重新渲染整行。换成 shallowReactive 后，状态变化不会自动触发渲染，你需要在状态变化的回调里显式调用 triggerRef 或替换整个对象引用。判断是否该用浅层响应式的标准：模板里是否只访问顶层属性（如 item.name，且 name 不变）？如果是，就可以用。如果模板内嵌了深层属性的计算，比如 item.detail.price，那要么改成只读计算，要么回到深度模式。验证方式：在组件的 render 或 setup 返回的函数里打印日志，对比使用前后同一数据变化时的渲染次数。

借助 v-memo 缓存列表渲染结果

在列表循环中，v-memo 指令可以缓存指定依赖不变时的子组件渲染结果。用法是 v-memo="[item.id, item.updatedAt]"，只有当数组内的值发生变化时，对应的节点才会重新渲染。这适合子组件渲染成本高且依赖明确固定的场景。但若依赖列表包含了所有可能变化的字段，就失去了优化意义；若依赖过少则可能显示脏数据。实际项目中可结合 computed 预先提取出真正影响渲染的关键字段作为依赖数组。

确定依赖字段时，先列出所有在子组件内部被 v-bind 或 v-if 用到的父组件数据。比如一个文章列表，子组件只展示标题和发布日期，那依赖就是 [item.id, item.title, item.publishDate]。如果标题很长，你可以考虑只依赖 item.id 和 item.updatedAt，但因为标题是显示字段，如果标题更新但 updatedAt 没变，就会显示旧标题。所以实际做的时候，先把子组件的输入属性写清楚，再挑出那些真正会变且影响展示的字段。验证方法：用 Vue Devtools 的时间线面板，观察列表更新前后组件实例的创建数。如果 v-memo 生效，应该只有依赖变化的那几项重新渲染，其他直接复用。

利用 key 控制组件生命周期

除了细粒度的响应式控制，key 属性也能用来避免不必要的更新。当组件内部状态依赖的 prop 或组合式函数返回值频繁变化但结构稳定时，可以通过动态 :key 强制整个组件重新挂载来替代深度响应式追踪。例如 :key="version" 配合 triggerRef 在需要时更新版本号，此时组件会完全重新执行 setup，清理旧副作用。这种方式适用于逻辑较简单、全量更新成本低于增量更新的场景，但会丢失内部临时状态，需谨慎使用。

一个典型例子是仪表盘组件，它接收一个 dataSource 对象，内部用 watch 复杂的变换逻辑。如果数据源整体改变频率低、但内部字段变化频繁，每次变化都触发 watch 重新计算可能比直接销毁重建更慢。这时候给仪表盘加上 :key="dataSource.id"，当数据源 id 变化时直接重建，旧组件被卸载，所有副作用自动清理。但要注意：如果组件内部有用户输入或未保存的临时状态，重建会丢失。所以只适用于那些状态完全由外部控制的“展示型”组件。验证方式：在组件的 onUnmounted 和 onMounted 里打日志，确认重建是否按预期发生。

以上方法都需要结合具体场景测试。没有哪个技巧能一键解决所有渲染问题，推荐的做法是先用 Vue Devtools 的渲染性能面板找出“渲染过多”的组件，再按顺序排查依赖、响应式深度、列表缓存、组件重建这四条路径。每次改完一个点，就对比优化前后的渲染次数，确认没有引入新问题。