插槽内容生命周期与预期不一致，核心在于插槽由父组件定义、浏览器投影进子组件Shadow DOM，游离于子组件响应式更新链和updated/render钩子之外；其内部变化不触发子组件重渲染，作用域插槽传递的是快照值而非响应式引用，动态插槽名切换也不触发mounted/unmounted，跨平台还存在兼容性限制。

插槽内容的生命周期和预期不一致，核心在于插槽不是由子组件创建或管理的，而是由父组件定义、由浏览器“投影”进子组件 Shadow DOM 的外部节点。它天然游离于子组件自身的响应式更新链和生命周期钩子之外。

插槽内容不触发子组件 updated / render

子组件的 updated 钩子只在自身模板重新渲染完成时执行。而插槽内容（比如 里显示的 xxx）是父组件模板的一部分，它的 DOM 节点在首次挂载后就已存在。后续父组件数据变化导致插槽内容文本更新，只是原生 DOM 的 innerText/innerHTML 变更，并不会让子组件走一遍 render() → updated() 流程。

• 子组件无法感知插槽内部文本、属性、class 的变化
• updated 不会因插槽内容变动而调用
• 即使子组件用了 slotchange 事件监听，也仅捕获插槽节点的增删，不反映内部响应式更新

作用域插槽的数据传递时机固定

作用域插槽（如 ）中绑定的 item 是子组件 每次执行 render() 时计算并传入的快照值，不是响应式引用。父组件通过 v-slot="{ item }" 接收的是一个普通对象，其属性变更不会自动同步。

• 若 item 是响应式对象（如 ref 或 reactive），需显式解构或监听其内部变化
• 若子组件内 item 被修改，父组件接收的插槽作用域对象不会自动更新——因为它是单次求值结果
• 常见误判：以为 {{ item.name }} 会随 item.name 改变而重渲染，实际依赖的是父组件是否重新执行了插槽内容的渲染

动态插槽名与条件切换的渲染断层

当插槽名由变量控制（如 ），Vue 并不会销毁旧插槽、重建新插槽。它只是切换 slot 元素的 name 属性，然后匹配对应具名内容。这个过程不触发任何组件实例的创建/销毁，也没有 mounted / unmounted 钩子。

• 从 header 切换到 footer，不会让 footer 内容里的组件重新 mounted
• 如果该内容含异步逻辑（如 onMounted(() => api.fetch())），它只在首次插入时执行一次
• 需要手动监听 currentSlot 变化，在 watch 中触发数据重载或状态重置

跨框架/平台（如 UniApp、小程序）的额外限制

部分平台对插槽实现做了简化或降级处理，例如：

• 微信小程序基础库早期版本不支持动态 slot 名，name="{{dynamicName}}" 可能被忽略
• UniApp 在 H5 和小程序间插槽编译行为不一致，slotchange 事件在某些平台不可靠
• 使用 v-if 控制插槽内容显隐时，若未加 key，组件实例可能被复用，导致生命周期钩子不按预期触发

本质上，插槽解决的是“内容分发”，不是“组件通信”。想让生命周期行为可控，就得把逻辑收敛到组件内部，或用 props + 事件替代过度依赖插槽更新。