前言
在大型 Vue 项目的业务迭代中，我们经常会遇到这样的场景：一个详情页底部挂载着各种功能按钮（如：拉黑、不感兴趣、举报、反馈）。这些按钮的显示与否，往往取决于详情接口返回的各种权限位。
很多开发者的第一反应是： "把逻辑封装进子组件，传一个权限标识进去不就行了？"
看起来很优雅，但实际上，这种做法隐藏着巨大的性能浪费和维护风险。今天，我们通过一次真实的业务重构，聊聊 Vue 组件设计中的 "逻辑层级对齐" 与 "单事实来源（SSOT）" 原则。
一、 滥用 Prop 传值的"多此一举"
假设我们有一个"拉黑权限" blackFlag，有些同学的组件化是这样的：
父组件：
xml
<!-- 父组件拿到了权限，却把结论传给子组件，让子组件自己去藏起来 -->
<Child :black-flag="blackFlag" />子组件：
xml
<template>
<div v-if="blackFlag">
<!-- 业务代码 -->
</div>
</template>
<script>
export default {
props: { blackFlag: Boolean }
}
</script>这种写法的三个"槽点"：
- 冗余的状态同步：关于"是否展示"这个事实，被父子组件同时观察，如果子组件内部不小心修改了对这个 Prop 的理解，或者在 computed 里又包了一层逻辑，就会出现"父组件想关，子组件关不掉"的情况。
- 多余的生命周期：哪怕 blackFlag 是 false，子组件也会被实例化，执行 data 初始化和生命周期钩子，白白占用内存。
- 脆弱的健壮性：如果子组件在 created 里注册了全局滚动监听或定时器，即便 UI 隐藏了，后台逻辑依然会"僵尸式"运行，极易引发内存泄漏或不可控的 Bug。
二、 健壮性原则：逻辑在哪里，控制就在哪里
重构的核心思路：让父组件决定子组件的"生死"，而不是"显隐"。
既然权限逻辑（接口请求过程）是在父组件完成的，那么父组件就应该掌握子组件的挂载权。
重构后的父组件：
xml
<!-- 权限不满足，子组件压根不会生效 -->
<Child v-if="blackFlag" />重构后的子组件：
xml
<template>
<div>
<!-- 只需要关注业务：既然我被创建了，我就一定要展示 -->
</div>
</template>
<script>
export default {
// 删掉冗余的 blackFlag Prop
}
</script>这样做带来的"绝对健壮性"：
由于 v-if 的 惰性（Lazy） 特质，当条件为假时，Vue 会确保子组件内部的任何 JS 逻辑、观察者（Watchers）、事件监听、甚至子组件的子组件都不会运行。这从物理层面上切断了任何潜在副作用产生的可能。
三、 进阶思考：代码加载了吗？
有些同学会问： "如果 v-if 把组件隐藏了，子组件的 JS 代码还会被浏览器加载吗？"
这需要分情况讨论：
情况 A：静态引入 (Static Import)
javascript
import Child from './Child.vue'; - 加载情况 ：代码会被打包进主 Chunk。浏览器打开页面时代码已下载，但在内存中处于"静默"状态，不执行、不实例化。
情况 B：动态引入 (Lazy Loading)
css
components: {
Child: () => import('./Child.vue')
}- 加载情况 ：高能预警！如果 v-if 条件一开始为 false，浏览器连这个 JS 文件都不会去下载。只有条件变为 true 的瞬间，才会触发网络请求拉取 Chunk。
结论：结合 v-if 和动态引入，你可以实现极致的性能优化------不仅节省内存和执行开销，连用户的网络带宽都省了。
四、 颗粒度权衡：如何选择组件策略？
并不是所有 v-if 都要往上提。我们可以根据 "逻辑归属权" 来快速站队：
- 外部决策型逻辑：如"当前用户是否有权限"、"是否从特定入口进入"。
-
- 策略：逻辑留父组件，v-if 挂在标签上。
- 自我决策型逻辑：如"该组件需要实时轮询一个接口来决定自己变不变红"。
-
- 策略：逻辑搬进子组件，获取逻辑与 v-if 共同留在子组件根节点。
五、结语
一个好的工程师，不应该只关注组件长什么样，更应该关注 "组件的生命周期从哪里开始，到哪里结束" 。
遵循 "谁管理状态，谁控制显隐" 的原则，能让你的代码告别脆弱的 Prop 同步，走向真正的健壮与高性能。