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 的所有 key，任何一个 value 的引用不同，就返回 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 将“是否更新”的决策点放得更早、做得更轻、默认覆盖得更全。真正需要手动干预的场景远比想象中少，但这些细节之间的权衡，正是组件化框架扎实落地的基础。