第2章 权限UI耦合的常见问题：权限判断散落、组件职责模糊、重复逻辑

在未应用State Hoisting的典型前端项目中，权限与UI的耦合往往以三种互相关联的形式出现：权限判断散落、组件职责模糊、重复逻辑。这三种问题共同破坏了模块边界，导致系统分层失效、组件无法独立复用、数据流混乱，最终使权限策略变更时面临高昂的维护成本。

2.1 问题对比总览

问题	典型表现	架构影响
权限判断散落	每个组件内部直接引用权限状态，不再通过统一路径	模块边界模糊，权限变更需修改N处
组件职责模糊	同一组件既负责UI渲染又负责权限校验，无法独立测试	组件复用性下降，业务逻辑与展示逻辑交错
重复逻辑	相同权限检查代码在多个组件/工具函数中重复出现	微小的权限规则变化引发大面积回归风险

2.2 代码示例：散落与重复

以下代码展示了两个业务组件中重复的权限判断逻辑。它们直接从Redux Store获取userRole，并各自实现“是否可编辑”检查。当权限规则从“admin”变为“admin+editor”时，两个组件都需要修改。

// ComponentA.jsx
import { useSelector } from 'react-redux';
function ComponentA() {
  const userRole = useSelector(state => state.user.role);
  const canEdit = userRole === 'admin';   // 散落判断①
  return (
    <div>
      {canEdit && <button>编辑A</button>}
      <span>内容A</span>
    </div>
  );
}

// ComponentB.jsx
import { useSelector } from 'react-redux';
function ComponentB() {
  const userRole = useSelector(state => state.user.role);
  const canEdit = userRole === 'admin';   // 重复判断②
  return (
    <div>
      {canEdit && <button>编辑B</button>}
      <span>内容B</span>
    </div>
  );
}

这种模式直接违反了单一职责原则，并且随着组件数量增长，权限逻辑的散落程度呈线性（甚至超线性）增加。

2.3 组件职责模糊带来的副作用

• 测试困难：组件必须挂载完整的Store才能验证UI分支，单元测试成本高。
• 复用受阻：想要在另一个模块复用该组件时，必须同时携带其依赖的权限上下文。
• 信任链路断裂：组件直接信任Store中的原始角色数据，缺乏中间层对权限状态的抽象与校验。

2.4 问题形成的系统结构图

下图中，三个业务组件（A、B、C）各自内嵌权限判断逻辑，它们都直接依赖底层的用户状态Store，并且组件之间通过Store间接耦合。当权限规则变更时，所有箭头的终点都需要调整。

2.5 对模块边界与系统分层的影响

在上述结构下，模块边界被权限逻辑穿透：本应属于“路由/中间件”层的权限校验被下沉到视图组件中，造成系统分层失效。组件不再仅仅依赖Props和数据流，而是直接与Store耦合，形成了隐式数据流。当需要增加一个新角色时，开发者必须逐一检查所有带有权限判断的组件，容易遗漏。

2.6 选型权衡（问题视角）

方案倾向	优点	隐患（对应本章问题）
在每个组件内直接读Store	实现简单，对初学者友好	权限判断散落、重复逻辑、组件耦合
使用高阶组件（HOC）包裹权限	抽取部分重复逻辑	HOC嵌套导致组件职责仍不清晰，调试困难
全局权限服务 + 组件订阅	逻辑集中，但订阅机制可能导致性能问题	若订阅不统一仍可能散落

2.7 落地验收标准（针对问题识别）

• 扫描检查：项目中使用“role”“permission”“canEdit”等关键词的组件数量与组件总数之比；若比例 > 30%，表明权限判断散落严重。
• 重复检测：对相同权限检查代码块（如 role === 'admin'）进行字符串匹配，出现超过3处即视为重复逻辑。
• 测试依赖：对任意一个业务组件的单元测试，若必须Mock整个Store而非仅传入Props，则说明组件职责模糊。