前言

在大型 Vue 项目的业务迭代中，我们经常会遇到这样的场景：一个详情页底部挂载着各种功能按钮（如：拉黑、不感兴趣、举报、反馈）。这些按钮的显示与否，往往取决于详情接口返回的各种权限位。

很多开发者的第一反应是： “把逻辑封装进子组件，传一个权限标识进去不就行了？”

看起来很优雅，但实际上，这种做法隐藏着巨大的性能浪费和维护风险。今天，我们通过一次真实的业务重构，聊聊 Vue 组件设计中的 “逻辑层级对齐” 与 “单事实来源（SSOT）” 原则。

一、 滥用 Prop 传值的“多此一举”

假设我们有一个“拉黑权限” blackFlag，有些同学的组件化是这样的：

父组件：

<!-- 父组件拿到了权限，却把结论传给子组件，让子组件自己去藏起来 -->
<Child :black-flag="blackFlag" />

子组件：

<template>
  <div v-if="blackFlag">
    <!-- 业务代码 -->
  </div>
</template>
<script>
export default {
  props: { blackFlag: Boolean }
}
</script>

这种写法的三个“槽点”：

1. 冗余的状态同步：关于“是否展示”这个事实，被父子组件同时观察，如果子组件内部不小心修改了对这个 Prop 的理解，或者在 computed 里又包了一层逻辑，就会出现“父组件想关，子组件关不掉”的情况。
2. 多余的生命周期：哪怕 blackFlag 是 false，子组件也会被实例化，执行 data 初始化和生命周期钩子，白白占用内存。
3. 脆弱的健壮性：如果子组件在 created 里注册了全局滚动监听或定时器，即便 UI 隐藏了，后台逻辑依然会“僵尸式”运行，极易引发内存泄漏或不可控的 Bug。

二、 健壮性原则：逻辑在哪里，控制就在哪里

重构的核心思路：让父组件决定子组件的“生死”，而不是“显隐”。

既然权限逻辑（接口请求过程）是在父组件完成的，那么父组件就应该掌握子组件的挂载权。

重构后的父组件：

<!-- 权限不满足，子组件压根不会生效 -->
<Child v-if="blackFlag" />

重构后的子组件：

<template>
  <div>
    <!-- 只需要关注业务：既然我被创建了，我就一定要展示 -->
  </div>
</template>
<script>
export default {
  // 删掉冗余的 blackFlag Prop
}
</script>

这样做带来的“绝对健壮性”：

由于 v-if 的 惰性（Lazy） 特质，当条件为假时，Vue 会确保子组件内部的任何 JS 逻辑、观察者（Watchers）、事件监听、甚至子组件的子组件都不会运行。这从物理层面上切断了任何潜在副作用产生的可能。

三、 进阶思考：代码加载了吗？

有些同学会问： “如果 v-if 把组件隐藏了，子组件的 JS 代码还会被浏览器加载吗？”

这需要分情况讨论：

情况 A：静态引入 (Static Import)

import Child from './Child.vue'; 

• 加载情况：代码会被打包进主 Chunk。浏览器打开页面时代码已下载，但在内存中处于“静默”状态，不执行、不实例化。

情况 B：动态引入 (Lazy Loading)

components: { 
  Child: () => import('./Child.vue') 
}

• 加载情况：高能预警！如果 v-if 条件一开始为 false，浏览器连这个 JS 文件都不会去下载。只有条件变为 true 的瞬间，才会触发网络请求拉取 Chunk。

结论：结合 v-if 和动态引入，你可以实现极致的性能优化——不仅节省内存和执行开销，连用户的网络带宽都省了。

四、 颗粒度权衡：如何选择组件策略？

并不是所有 v-if 都要往上提。我们可以根据 “逻辑归属权” 来快速站队：

1. 外部决策型逻辑：如“当前用户是否有权限”、“是否从特定入口进入”。

• • 策略：逻辑留父组件，v-if 挂在标签上。

1. 自我决策型逻辑：如“该组件需要实时轮询一个接口来决定自己变不变红”。

• • 策略：逻辑搬进子组件，获取逻辑与 v-if 共同留在子组件根节点。

五、结语

一个好的工程师，不应该只关注组件长什么样，更应该关注 “组件的生命周期从哪里开始，到哪里结束” 。

遵循 “谁管理状态，谁控制显隐” 的原则，能让你的代码告别脆弱的 Prop 同步，走向真正的健壮与高性能。