Patch过程中组件实例更新逻辑深度解析

在Vue 3中，组件实例是否需要更新，并非通过diff逐层比较得出，而是由shouldUpdateComponent这个守门函数提前决定放行或驳回。这一机制比许多开发者想象的更为前置，也更加轻量。

当父组件执行patch时，在真正比对子组件的VNode之前，这个函数就已经被调用了。它接收新旧两个VNode（n1和n2）作为参数。只有当它返回true时，后续的diff、re-render、DOM更新等一系列流程才会实际执行；如果返回false，则整个子组件子树完全跳过，不会进行任何操作。

触发这个逻辑的前提条件其实很简单：子组件已经完成挂载（即n1.component存在），并且n2.type属于组件类型。它并非在patch函数内部运行，而是在processComponent或patchComponent阶段被主动调用。关键还在于，这是一个纯函数——不依赖this，没有副作用，仅凭两个VNode参数做出决策，因此天然具备轻量、可测试、可复用的特点。

默认浅比较：仅比对这三项关键内容

Vue 3的默认实现会依次检查以下三类引用是否发生了变化，比对方式采用===或Object.is：

• Props：遍历新旧props的所有键，任何一个值引用不同，就会返回true，表示需要更新。
• Children：直接比较新旧children的引用是否相同，不会递归深入对比每个子节点的具体内容。
• Slots：检查新旧slots是否指向同一个对象。这里有一个常见陷阱——函数式插槽每次渲染都会生成全新的函数引用，因此极易被误判为“需要更新”，进而触发不必要的重渲染。

三者中只要有一条命中，就会被判定为需要更新；全部引用不变，才会返回false，跳过整个patch。这个默认策略已经覆盖了绝大多数场景，多数情况下开发者无需额外操心。

自定义shouldUpdateComponent的典型用法

在某些场景下，默认策略确实不够精细化，你可以在defineComponent中显式声明shouldUpdateComponent来覆盖默认逻辑。例如：

• 忽略那些不影响视图渲染的prop变化，比如仅用于埋点的debugId或trackKey；
• 根据业务状态做条件式更新，比如只在nextVNode.props.status === 'done'时才允许组件重渲染；
• 手动控制插槽稳定性，将插槽函数缓存为ref或memoized版本，避免因引用变化而反复触发更新。

需要注意的是，这个函数是组件定义选项，不能写在setup返回的对象里面。

与React的shouldComponentUpdate有什么本质区别

虽然名字相似，但在设计哲学和实际工作方式上，两者的定位完全不同：

• React的shouldComponentUpdate是一个实例方法，能够访问this.props和this.state，默认返回true，几乎必须重写才能获得优化效果，对开发者而言负担较重。
• Vue的shouldUpdateComponent则是一个无状态的纯函数，只接收VNode，更轻量、更可控，而且默认已经启用了浅比较，绝大多数情况下根本无需干预。
• 它还天然适配编译时优化——比如静态提升、patch flag——这些都是在响应式更新链路上比React更前置、更底层的一道防线。

一句话总结：Vue 3将“是否更新”这个决策点放得更早、做得更轻、默认覆盖得更全。真正需要开发者动手干预的场景远比想象中少，而这些细节之间的博弈，恰恰是组件化框架真正走稳的路。