“守卫组合拳”指前端权限控制中全局前置守卫、路由独享守卫、组件内守卫三级联动模式，分阶段校验角色准入、页面权限与ui元素显隐，协同后端实现rbac闭环落地。
“守卫组合拳”不是标准术语，而是对前端权限控制中**多层路由守卫协同工作模式**的通俗叫法。它指在 Vue、React 或 Angular 等现代前端框架中，不依赖单一守卫，而是通过全局前置守卫 + 路由独享守卫 + 组件内守卫三级联动，分阶段拦截、校验、细化权限，从而扎实落地 RBAC 模型——尤其适用于角色多、权限细、数据敏感的企业级系统。
为什么单靠一个守卫不够？
RBAC 的真实落地场景远比“登录后能进首页”复杂：管理员能删订单，销售经理只能导出报表，客服专员仅能查看自己跟进的客户。若只用全局 beforeEach 做粗粒度判断（比如只校验是否登录），就会漏掉按钮级、API 级、甚至行级数据的越权风险。守卫组合拳的本质，是把权限校验拆解到不同环节，各司其职：
-
全局守卫：管“能不能进这个页面”，做角色准入（如：非
order_manager角色直接跳转 403） -
路由守卫（
beforeEnter）：管“进这页前要不要额外检查”，比如该页面需访问财务模块，得再校验是否有finance:read权限 -
组件守卫或逻辑守卫：管“页面里某个按钮/接口/表格列要不要显示”，比如根据用户角色动态渲染“删除”按钮，或拦截调用
/api/orders/delete的请求
怎么组合？三步落地 RBAC
以 Vue 3 + Pinia + Vue Router 4 为例，结合企业常见 RBAC 数据结构（用户带 roles: ["sales_manager"]，后端返回 permissions: ["router:dashboard", "button:report_export"]）：
-
第一步：全局守卫做角色兜底
在router.beforeEach中，检查目标路由元信息meta.roles（如{ roles: ["admin", "sales_manager"] }），比对当前用户角色列表。不匹配则中断导航，避免未授权用户看到空白页或报错弹窗 -
第二步：路由级守卫做权限细化
对关键路由（如报表页、审批页）配置beforeEnter，调用权限服务校验具体权限码（如"report:export"）。可结合异步加载，避免权限数据未就绪时误判 -
第三步：组件内用指令或 Composable 控制 UI 元素
封装v-has-permission指令或usePermission("button:order_delete")Hook，在模板中精准控制按钮、菜单项、Tab 标签的显隐。这样即使路由被绕过，敏感操作也无法触发
配合后端，才真正闭环
前端守卫只是防线的一环。真正的 RBAC 落地必须前后端协同：
- 后端需按 RBAC 模型校验每次 API 请求（不能只信前端传来的角色），校验依据是用户实际拥有的权限码，而非角色名（防角色伪造）
- 权限码命名需统一规范，例如
resource:action（customer:read、order:delete），便于前端解析、后端策略引擎（如 OPA）复用 - 前端获取权限数据应走独立鉴权接口（如
GET /api/v1/me/permissions），而非从登录响应里硬塞，确保权限实时性与审计可追溯
守卫组合拳不是堆砌技术，而是让权限逻辑在合适的位置做合适的事。它把 RBAC 从一张静态矩阵表，变成运行时可感知、可干预、可审计的活体机制。
