Uni-app 性能天坑：为什么 v-if 删不掉 DOM 节点

🧑‍💻 写在开头

点赞 + 收藏 === 学会🤣🤣🤣

在开发自定义 Swiper 或长列表组件时，为了优化性能，我们通常会给每一项加上懒加载逻辑：

<view class="item"><template v-if="shouldRender"><slot :name="'slot-' + index" /></template>
</view>

神奇的事情发生了： 哪怕 shouldRender 是 false，打开小程序调试器一看，WXML 树里依然排满了 view slot="slot-0"、view slot="slot-1"... 里面甚至还塞满了图片节点。

结论：你的 v-if 只是“隐藏”了视觉，内存和 DOM 压力一点没减。

---

一、 具名插槽是“物理坑位”

为什么 v-if 失效了？因为在微信小程序底层，具名插槽（Named Slots） 的实现逻辑是静态枚举。

1. 预编译挖坑：小程序原生不支持动态插槽名。Uni-app 编译器为了兼容 Vue，会根据你的循环逻辑，在 WXML 里预先写死所有的占位符（如 slot="d-0", slot="d-1"）。
2. 渲染权倒置：在具名插槽模式下，父组件拥有内容的实例化权。父组件会先把所有内容节点生成好，然后再“分发”给子组件。
3. 隔离失败：子组件里的 v-if 只能决定子组件自己是否显示，但挡不住父组件已经产生的物理节点。这就好比虽然你把家门关了（v-if=false），但邻居已经把货卸在了你门口（DOM 占位） 。

---

二、 作用域插槽是“动态模版”

要实现真正的懒加载（随 v-if 销毁 DOM），必须重构为作用域插槽（Scoped Slots） 。

1. 子组件改造：变“多坑”为“单模板”

不要再给插槽起动态名字，统一使用带作用域的默认插槽或具名插槽。

<view v-for="(item, index) in list" :key="index"><template v-if="shouldRender(index)"><slot name="content" :item="item" /></template>
</view>

2. 父组件调用：禁止使用 v-for 填坑

这是最关键的——父组件不再负责循环产生节点，只提供渲染模板。

<Swiper :list="dataList"><template v-slot:content="{ item }"><image :src="item.url" /></template>
</Swiper>

三、 循环 slot 不会重名冲突吗？

很多同学看到这里会问： “子组件循环 20 次 slot name="content"，在 WXML 里难道不会报 ID 冲突或渲染覆盖吗？”

真相是： 当你使用“作用域插槽”时，底层渲染逻辑发生了本质改变。

• 具名插槽（旧） ：编译器会生成 d-0, d-1... 等多个不同的物理坑位。
• 作用域插槽（新） ：编译器会将插槽内容封装成一个微信小程序原生的 template。在 WXML 层面，子组件循环的是同一个“模板调用”，而不是多个“物理坑位”。

这就好比：具名插槽是盖好了 20 间空房子等分发；而作用域插槽是给了一张图纸，子组件循环 20 次，只有遇到 v-if="true" 时才照着图纸现盖一间房。既然是现盖，自然不存在重名抢坑的问题。

---

四、 为什么换成作用域插槽就生效了？

这是底层架构的质变：

• 实例化时机改变：实例化内容的控制权移交给了子组件。
• 按需生成：只有子组件执行到 <slot /> 那一行代码时，父组件定义的“模板”才会动态转变为真正的 DOM。
• 地基都没了：如果 v-if="false"，父组件的内容在内存里连影子都不会出现。

---

五、 避坑小结

如果你在 Uni-app 开发者工具里发现 DOM 节点数不对劲，请检查以下两点：

1. 是否在循环里用了动态具名插槽？ （:name="'xxx' + index"
2. 父组件是否也写了 v-for 去填坑？ 确保父组件只提供 <template v-slot:xxx> 声明。

如果对您有所帮助，欢迎您点个关注，我会定时更新技术文档，大家一起讨论学习，一起进步。