当vue.diff遇上了扩展运算符(...)

这是一个非常经典的 Vue 响应式性能陷阱。为了完善这个故事背景并深入剖析事故原因，我们可以将其扩写为一个实际开发中的"性能优化事故"案例。以下是扩写后的完整内容：

故事背景

项目背景 ：某电商后台管理系统正在开发"商品批量编辑"功能。该页面表单极其复杂，包含几十个字段，分散在不同的业务逻辑域中。 业务场景 ：开发人员需要将"基础信息"（如商品名称、编号）和"价格库存"（如售价、库存量）两部分数据合并传递给一个通用的 LogPreview 组件（即文中的 ChildItem），用于实时生成变更日志预览。 代码场景复刻 ：为了快速上线，开发人员简单复刻了业务代码，写了一个 Demo。逻辑看似清晰：父组件维护三个响应式对象 a、b、c，通过 v-model 绑定输入框，并将 a 和 b 合并传给子组件展示。

事故原因

1. 事故现象

在测试过程中，发现了一个诡异的现象：

当用户在输入框 c（对应数据 ref({c: 3})）中输入内容时，原本应该毫无关联的 ChildItem 子组件竟然发生了重新渲染。
子组件内的"当前时间"一直在刷新，说明子组件在不断更新。
在真实业务中，由于 ChildItem 内部包含了复杂的计算和大量 DOM 节点，这种不必要的重渲染导致了输入时明显的卡顿和性能损耗。

2. 核心原因剖析

问题的根源在于父组件模板中这行代码：

html 复制代码

<ChildItem :data="{...a, ...b}"></ChildItem>

原因一：模板中的"隐形"新对象

在 Vue 的模板编译机制中，:data="{...a, ...b}" 并不是一个静态的引用。每当父组件因为任何原因 重新渲染时（即使只是修改了无关变量 c），模板中的表达式 "{...a, ...b}" 都会被重新执行。这行代码在 JavaScript 运行时层面等同于：

javascript 复制代码

// 每次渲染都创建一个全新的堆内存对象
const newData = new Object({ ...a.value, ...b.value });

因此，虽然 a 和 b 的内容没变，但每次渲染都会生成一个引用地址完全不同的新对象。

原因二：Props 的浅比较

Vue 的响应式系统判断 Props 是否变化，对于对象类型，采用的是引用比较。

第一次渲染 ：传递对象引用地址 ADDR_1。
修改 c 触发父组件更新 ：模板重新执行，生成新对象引用地址 ADDR_2。
Diff 算法判定 ：ADDR_1 !== ADDR_2，Vue 认为 Props 发生了变化。
结果：子组件被迫更新。

原因三：不必要的渲染扩散

本案例中，c 的变化导致了 ChildItem 的更新，这是典型的"过度渲染"。由于 ChildItem 接收的 data 在逻辑上并未改变（值没变，只是引用变了），这种更新完全是多余的。

3. 扩展实验证明

可以通过在子组件中打印日志来验证：

javascript 复制代码

// 在 ChildItem.vue 中
import { watch } from 'vue';
watch(() => props.data, (newVal, oldVal) => {
  console.log('Props data changed');
  console.log('Old Reference:', oldVal);
  console.log('New Reference:', newVal);
  console.log('Is Same Object?', newVal === oldVal); // 结果永远是 false
}, { deep: true });

你会发现，只要父组件有任何风吹草动（比如 c 变化），控制台就会输出 Props data changed，证明了引用地址的变更触发了更新。

4. 正确的解决方案

要避免这个问题，必须保证传递给子组件的对象引用稳定。应当使用 computed 对数据进行缓存。 修正后的父组件代码：