diff算法处理插槽的核心是父组件决定slots引用是否变更，触发子组件重新render并执行自身diff；插槽vnode惰性生成、不跨patch复用，更新严格遵循父先子后时序。

Diff 算法处理插槽内容的动态变化，核心在于插槽不是独立组件，而是父组件 render 函数中“按需求值”的函数式内容；它不参与子组件自身的 diff 流程，而是在父组件 patch 到子组件 VNode 时，由父决定是否更新子组件的 slots 对象，并触发子组件重新 render —— 此时子组件内部才基于新 slots 执行自己的 diff。

插槽内容何时被重新生成？

插槽内容（即 slots.default、slots.header 等）本质是函数，在父组件 render 阶段被调用，返回一组 VNode。只要父组件响应式依赖变化（比如 v-if 条件翻转、v-for 数组更新、作用域插槽中传入的 props 变化），父的 render 就会重新执行，从而生成新的插槽 VNode 数组。

关键点：

• 插槽 VNode 是惰性构造的：只有父 render 跑了，它才存在；不会提前缓存或跨 patch 复用
• 即使子组件实例未销毁，只要父传入的 slots 引用变了（哪怕内容相同但函数不同），Vue 就认为插槽已更新
• 子组件自身无法感知插槽“内容变没变”，只认 slots 对象引用是否变更（靠 shallowEqual 判断）

父子 Patch 顺序如何影响插槽更新？

插槽更新严格遵循“父先于子”的 patch 时序：

• 父组件 patch 进入子组件 VNode 节点时，先调用 updateComponentPreRender 更新子实例的 props 和 slots
• 若 slots 引用变化，会标记子组件需要 re-render（即使 props 没变）
• 随后触发子组件 render()，产出新 VNode；此时子组件内部才开始 diff 自己的 children（含插槽内容渲染结果）
• 子组件的 diff 不会回溯去比对“上一次插槽生成的 VNode”，它只比对自己本次 render 输出的新旧 VNode 树

举例：父组件中写 <child><p>{{ msg }}</p></child>，当 msg 改变：

• 父 render 重新执行 → 新的 slots.default 函数被调用 → 返回新的 <p>...</p> VNode 数组
• 父 patch 到 Child VNode → 发现 slots 引用不同 → 触发 Child 的 pre-render 更新
• Child 再次 render → 其模板中 <slot></slot> 展开为新 VNode → 进入 Child 自身的 patchChildren 流程

带 key 的作用域插槽怎么 diff？

作用域插槽（如 v-slot:item="{ data }"）本身不带 key，但它的使用位置可能在 v-for 中。真正起作用的是父级 v-for 为每个循环项生成的 slot VNode 自带 key。

这时 Vue 会：

• 将插槽内容作为子组件的 slots 一部分传入，key 保留在其生成的 VNode 上
• 子组件 render 后，插槽展开的节点形成一组带 key 的子节点
• 子组件内部执行 patchKeyedChildren，利用 key 做精准复用和移动，而非暴力替换
• 所以“列表中某一项插槽内容变” → 父生成新 VNode 带相同 key → 子 diff 识别为同一节点 → 只更新 props 或内部文本，不卸载重挂

为什么不能在子组件 created 中读取插槽 DOM？

因为插槽内容属于父组件 render 的产物，子组件生命周期完全不控制它的生成时机：

• created 阶段：父 render 还没跑，slots 可能为空或默认 fallback，且无真实 DOM
• mounted 阶段：父已完成 patch，子也完成首次 render，插槽内容已挂载到子组件 DOM 中
• 若需访问插槽 DOM，必须等 onMounted + nextTick（确保子组件内插槽已渲染完毕）

不复杂但容易忽略