一、状态提升核心原理：状态上移、单向数据流、组件通信解耦

1.1 问题背景：权限 UI 耦合的根源

在权限管理场景中，常见实现是将权限判断逻辑直接嵌入到组件内部，例如通过 v-if / hasPermission 决定按钮显隐。这种做法看似直观，却导致状态（权限）与 UI 渲染强耦合，带来以下架构风险：

• 组件职责过载：按钮组件既要负责渲染，又要感知全局权限状态。
• 数据变更链路混乱：权限更新时，无法精确追踪影响范围。
• 测试与复用困难：组件脱离权限上下文无法单独验证。

1.2 状态提升：将共享状态迁至最近公共祖先

状态提升（State Hoisting）的核心思想是：将多个组件共享的状态，提升到它们的最近公共祖先（LCA）节点中管理，祖先节点通过 props 向下传递状态与回调函数，子组件不再拥有或直接修改共享状态。

概念	提升前（耦合）	提升后（解耦）
状态归属	各子组件各自维护权限判断	统一由父组件/容器组件管理
数据流向	子组件直接调用全局权限 API	单向向下传递，事件向上回传
组件职责	UI + 权限逻辑混合	仅接收 props 做展示
变更影响	权限变化波及所有使用组件	仅在 LCA 节点触发重渲染
信任模型	子组件可能绕过权限检查	权限决策与执行严格分离

1.3 单向数据流：从权力中心到视图边缘

状态提升后，系统形成清晰的单向数据流：

1. 权限状态源：位于根容器或专用存储层（如 Vuex / Pinia / Context）。
2. 过滤与转换：LCA 节点从源获取权限快照，根据业务规则生成各子组件所需的 visible / disabled / variant 等 props。
3. 向下传递：子组件只接收这些「已裁决」的 props，不接触原始权限 。
4. 事件回传：用户交互（如点击）通过回调函数向上传递，由 LCA 节点统一处理。

1.4 核心代码示例：从耦合到提升

反例（耦合）：

<!-- ButtonComponent.vue -->
<template>
  <button v-if="hasPermission('delete')" @click="deleteItem">
    删除
  </button>
</template>

<script>
import { hasPermission } from '@/permission'
export default {
  methods: {
    deleteItem() { /* ... */ },
    hasPermission  // 函数注入组件
  }
}
</script>

正例（状态提升）：

<!-- ParentContainer.vue -->
<template>
  <div>
    <ButtonComponent
      :visible="canDelete"
      :action="handleDelete"
    />
  </div>
</template>

<script>
import { usePermission } from '@/permission'
export default {
  setup() {
    const permission = usePermission()
    const canDelete = permission.has('delete')
    const handleDelete = () => { /* 由父节点执行删除逻辑 */ }
    return { canDelete, handleDelete }
  }
}
</script>

<!-- ButtonComponent.vue -->
<template>
  <button v-if="visible" @click="action">
    删除
  </button>
</template>

<script>
export default {
  props: {
    visible: Boolean,
    action: Function
  }
}
</script>

1.5 架构图：状态提升后的组件分层与数据流向

1.6 模块边界与系统分层

状态提升后，系统明确分为三层：

• 数据层：权限状态源（Auth Store / Context Provider），负责权限数据获取与缓存。
• 编排层：容器控制器（LCA 节点），负责权限裁决、业务策略组合、子组件 props 生成。
• 表现层：子组件（UI Component），仅依赖 props 做展示，无权限感知。

1.7 组件职责与信任链路

组件类型	职责范围	信任边界
权限源	提供原始权限集，维护认证状态	仅与编排层交互
容器控制器	权限过滤 → 业务决策 → 输出 props	被视为「信任锚点」
表现子组件	接收 props → 渲染 UI → 回传事件	不信任子组件做任何权限判断

1.8 选型权衡与风险点

• 权衡 1：提升粒度。过度提升会导致容器节点 props 过多，增加复杂度；提升不足又会留下耦合点。建议以「页面区域」为单位粒度。
• 权衡 2：性能开销。状态提升使 LCA 节点成为重渲染瓶颈，配合 React.memo / computed 剪枝。
• 风险点 1：深层传递（prop drilling）。当组件层级超过 4 层时，考虑使用组合式 API 或依赖注入，但必须保证权限决策仍集中在靠近根的位置。
• 风险点 2：事件回传路径过长。回调函数层层传递可能导致上下文丢失，推荐使用稳定引用 + dispatch 模式。

1.9 落地步骤

1. 审计现有组件：标记所有包含 hasPermission、v-if=“auth” 的组件。
2. 定位 LCA 节点：根据组件树找到这些组件的最近公共祖先容器。
3. 提取权限状态：将权限判断逻辑上移至 LCA 节点的 computed 或 setup 中。
4. 定义 props 接口：为子组件设计最小 props 集（如 visible、disabled、action）。
5. 移除子组件权限代码：删除子组件内的 hasPermission 调用及所有权限相关 import。
6. 验证单向数据流：确认子组件没有通过任何方式反向修改权限状态源。

1.10 验收标准

验收项	预期表现
子组件无权限依赖	子组件 props 中没有任何 permission / auth 字段
LCA 节点稳定	修改权限源时，仅 LCA 节点及受影响的子组件重渲染
事件回传完整	子组件触发 action 能够正确被 LCA 节点捕获并处理
测试脱离权限上下文	子组件测试仅需 mock props，无需 mock 权限 API
架构入侵为零	子组件代码中不含 import { hasPermission } 等权限相关语句