权限与设计系统

• 前端代码与数据对用户完全可见可篡改的前提
• 后端必须独立校验权限的原因（绕过 UI 直调 API）
• 前端权限的定位（体验优化、数据最小暴露）与设计原则

前端运行在用户设备上，其代码、状态与请求都可被用户或攻击者读取、修改与重放，因此前端权限判断（隐藏按钮、过滤菜单）只是"界面层约束"——为正常用户提供清晰的可用性，不具备任何安全强度：攻击者可绕过 UI 直接调用 API、修改请求参数、篡改本地状态。安全边界必须在后端：服务端对每个请求独立鉴权（用户身份、资源归属、操作权限），校验请求参数与业务规则，前端下发的"权限清单"仅作为展示依据而非授权凭证。工程设计原则：前端按后端返回的权限数据渲染 UI（隐藏/禁用无权限入口），API 设计遵循"后端为准"，前端权限数据有默认拒绝（拿不到权限数据时隐藏或降级），重要操作（支付、删除）后端二次校验；同时避免在权限接口中返回超集数据（如返回全部用户列表由前端过滤），前端只拿最小必要数据。

本题考察权限体系的第一性原理。答题核心是"前端不可信"的前提推导出"后端独立鉴权、前端仅体验优化"的结论，以及最小数据暴露与默认拒绝等设计原则。

• ABAC 的策略模型（主体/资源/环境属性 + 策略规则）
• 动态决策场景（时间、地点、数据归属、多因子）
• ABAC 与 RBAC 的组合实践与复杂度控制

ABAC 的授权决策基于属性组合而非固定角色：主体属性（用户、部门、职级）、资源属性（数据归属、密级）、环境属性（时间、地点、设备、风险分），策略引擎按布尔规则（如"本人或直属上级可查看，且仅在工作时间"）实时计算是否放行，天然支持动态与上下文敏感的场景（地域限制、数据归属校验、风控分级放行）。相对 RBAC：ABAC 表达力强、可应对细粒度与多维度场景（数据级权限、多租户隔离），但策略分散难管理、性能开销大（每次决策计算）、易出现规则冲突。工程实践：组合使用——角色做粗粒度主体分组（RBAC 简化管理），属性策略做细粒度动态决策（ABAC 覆盖数据级与环境条件），策略集中到后端（如 OPA/Casbin 支持属性模型）统一评估，前端只接收决策结果渲染 UI；权限评估下沉数据层（SQL 注入数据过滤条件）保证"可见即有权"。

本题考察权限模型选型的深度。答题核心是 ABAC 的属性-策略-决策模型与动态场景价值、相对 RBAC 的优劣，以及"RBAC 粗粒度 + ABAC 细粒度"的组合实践。

• 关键操作的威胁模型（会话劫持、越权、误操作）
• 二次确认的强度分级（轻确认、密码、MFA/Passkey）
• 前端交互与后端强校验的配合（一次性凭证、防重放）

关键操作（支付、转账、改密、删除）风险高，仅靠登录态不足：会话可能被劫持、操作可能越权或误触，因此需要二次确认。强度分级：低危关键操作（删除条目）用交互确认（弹窗核对）；中危（较大金额）用重新输入密码或短信验证码；高危（大额转账、改绑手机）用 MFA（TOTP）或 Passkey（WebAuthn，设备级生物识别+非对称签名，抗钓鱼）。工程要点：二次确认必须是"后端发起的挑战"而非前端自证——前端提交操作意图，后端生成一次性挑战（challenge/凭证），用户验证后提交签名/验证码，后端校验通过才执行；凭证一次有效、带时效与操作绑定防重放；前端负责友好交互（金额核对、风险提示、验证失败的降级路径），不负责信任判定。与权限体系配合：二次确认结果计入审计日志，频繁关键操作触发风控（限频、提升验证强度）。

本题考察高危操作的纵深防御。答题核心是"强度分级（确认/密码/MFA-Passkey）+ 后端挑战-响应模型 + 一次性防重放"设计，以及审计与风控联动。

• 不可信前端的假设（UI 可绕过、请求可伪造）
• 权限边界：展示层（前端）与执行层（后端）的职责切分
• 隐藏 UI 的体验价值与后端校验的兜底设计

边界划分原则：前端隐藏/禁用无权限 UI（菜单、按钮、路由）只为用户体验——不展示用不了的功能、减少误导与报错；后端对每个接口独立校验才是权限的真正执行点，二者职责互补不可替代。不可信前端的设计要求：所有敏感数据由后端按权限裁剪返回（前端不做"拿到全量再过滤"）；后端校验不仅查"是否有权限码"，还要校验资源归属（数据级）、操作合法性（状态机约束）与频率；前端权限数据（权限码列表）仅用于渲染，不参与信任决策；关键操作加二次确认与服务端挑战；接口层面防篡改（签名/参数校验）与防重放；前端被绕过时后端必须返回 403 且不留可利用的旁路（如隐藏接口仍可调用但无数据返回）。同时前端权限数据过期处理：权限变更时后端在下一次请求返回最新权限，前端据此刷新 UI。

本题考察"展示与执行分离"的权限架构。答题核心是明确前端隐藏 UI 的体验定位与后端校验的安全定位，并给出数据裁剪、归属校验、防篡改防重放等不可信前端设计要点。

• Storybook 的组件开发、文档与可视化验证价值
• Bit 的组件独立版本化与跨仓库分发（bit install）能力
• 两者在设计系统协作中的分工（开发预览 vs 发布消费）

Storybook 是组件开发环境：每个组件独立渲染、配置各状态（loading/error/尺寸/主题），支持交互测试（play 函数）、快照与无障碍检查，还能可视化设计令牌（Design Tokens 插件展示色板/间距），价值在于"开发-评审-验证"闭环与组件文档化。Bit 是组件级版本化与分发平台：组件独立打包版本（语义化版本）、独立文档与独立测试，通过 bit install 从远端（bit.cloud/私有服务）按组件粒度安装到任何仓库，支持跨项目复用与更新传播（升级组件即提升版本），价值在于"组件作为可独立交付的软件单元"。配合模式：开发期用 Storybook 做组件开发与预览、发布前用 Chromatic 视觉回归；发布与消费用 Bit 做版本管理与分发；设计令牌可由 tokens 仓库独立版本化，组件发布时锁定 tokens 版本。选择：单一应用内复用选 Storybook；多项目/多团队共享组件库选 Bit；大厂常见组合为"Storybook 开发 + Bit/npm 包分发 + tokens 独立版本"。

本题考察组件工程化工具链。答题核心是 Storybook"开发验证"与 Bit"版本分发"的分工定位，以及 tokens 版本锁定与跨仓库消费的配合模式。

• 导航守卫的执行时机（跳转前拦截）与全局/路由级/组件级分层
• 组件内检查（onMounted/渲染时）的适用场景与局限
• 两者配合的权限模型（守卫拦截路由、组件兜底数据权限）

导航守卫（全局 beforeEach、路由级 beforeEnter、组件内 beforeRouteEnter 等）在路由跳转前执行，适合"整页级权限"：无权限时重定向 403/登录页，避免页面渲染与无效请求；可做权限码校验、登录态校验、meta 配置校验，且守卫拦截后不会触发组件挂载，体验干净。组件内检查（渲染条件 v-if 权限、onMounted 时校验、接口数据驱动）适合"页面内部区块级与数据级权限"：同一个页面不同角色看到不同卡片/按钮、接口返回数据决定可见性，这些守卫管不到，因为守卫粒度是"路由"而非"组件块"。取舍与配合：守卫做路由访问控制（能否进入页面），组件内检查做页面元素与数据控制（进入后看到什么），两层都依赖统一的权限源（store 或 hook）；注意守卫内避免耗时请求（可预取权限数据再放行）、组件内检查避免"权限数据未加载时闪烁"（用 loading 态）；权限变更时守卫与组件检查都要响应更新。

本题考察权限在前端的分层落地。答题核心是"守卫管页面级、组件检查管块/数据级"的分工模型，以及权限数据统一源与加载时序的工程细节。

• 后端菜单树的数据结构（嵌套、路由、权限码、显隐控制）
• 前端递归组件的渲染与权限过滤位置
• 边界处理（孤儿节点、层级控制、缓存与刷新）

数据契约：后端按当前用户权限生成菜单树，节点字段含 id、name、path、icon、permissions（需要的权限码）、children、visible（显隐开关）等；前端拿到树后渲染，前端通常不再做权限过滤（后端已裁剪），只做递归渲染与路由映射——菜单树与路由表同构（path 对应路由名），点击菜单即导航。递归渲染实现：菜单组件接收 tree 数据自递归（Vue 递归组件/React 递归函数），渲染层级结构；要点：空 children 隐藏展开箭头、叶子节点点击路由跳转、外部链接节点（target 处理）。边界处理：后端返回的树须保证无孤儿节点（父级无权限时子级一并裁剪）与层级受控（如最多 3 级，超出用业务页承接）；菜单与路由不一致时（菜单隐藏但路由可达）由路由守卫兜底；菜单数据缓存（sessionStorage）配合权限变更刷新（重新拉取）；性能上大菜单树用扁平化 + parentId 映射或懒加载渲染。

本题考察菜单权限的经典实现。答题核心是"后端裁剪生成菜单树、前端递归渲染与路由映射"的分工，以及孤儿节点、守卫兜底、缓存刷新等边界治理。

• 权限码的命名规范与粒度（模块:资源:动作）
• 指令/组件/Hook 三种按钮权限实现方式
• 权限码的集中管理（枚举、类型安全、后端一致）

权限码设计：采用分层命名 {domain}:{resource}:{action}（如 order:detail:export），粒度到"资源+动作"级别，避免过细（每按钮一码导致爆炸）或过粗（只能控制页面）；权限码前后端共用同一字典，后端下发用户拥有的权限码集合，前端据此渲染。按钮级实现三方式：自定义指令（Vue v-permission="'order:export'" 在 mounted 时无权限移除/禁用元素，React 用高阶组件或条件渲染封装）；组件封装（权限包裹组件，无权限渲染 null 或禁用态）；Hook（usePermission(code) 返回布尔，配合 v-if）。治理要点：权限码集中定义（TS 常量/枚举）避免魔法字符串、接入 ESLint 校验；权限变更响应（权限集合更新后重新渲染）；无权限按钮默认"隐藏"还是"禁用"按业务定（隐藏更安全、禁用可解释）；同时按钮权限只是 UI 呈现，后端接口必须同码校验，权限码字典版本化避免前后端漂移。

本题考察按钮级权限的实现体系。答题核心是权限码的命名粒度规范、三种实现方式（指令/组件/Hook）的适用性，以及字典集中管理与前后端一致的治理。

• 不一致的场景枚举（菜单缺失、路由越权、权限树过期）
• 路由守卫与菜单渲染的兜底协作
• 用户体验（404/403 降级、重定向、自动补全）

不一致来源：后端权限数据过期/裁剪错误、前端路由表与菜单配置漂移、权限变更未同步刷新，典型情形——菜单没显示但路由可直达（深链接）、菜单显示了但路由已被移除（旧缓存）、菜单指向的路由无权限（权限回收）。回退策略分层设计：路由层兜底——全局守卫校验当前路由所需权限，无权限重定向 403 页（带返回入口）或登录页，防深链接越权；菜单层兜底——渲染时校验每个菜单节点的路由是否可达（路由表存在且权限满足），不可达节点隐藏或置灰；数据层兜底——路由页面加载数据时接口返回 403 则触发全局降级（提示无权限并清除相关权限缓存，重新拉取权限树刷新菜单）。同时建立一致性保障：菜单树与路由表由同一配置源生成（schema 驱动）、权限变更走"推送+拉取"双通道、发布时 CI 校验菜单-路由映射完整性。

本题考察权限数据不一致的韧性设计。答题核心是"路由守卫防越权 + 菜单渲染校验 + 403 降级自愈"三层 fallback，以及配置同源与 CI 校验的一致性保障。

• meta 中声明权限字段（roles/permissions/guestOnly）的模型
• 守卫/loader 读取 meta 做校验的统一入口
• 声明式的可维护性（权限与路由同处定义、静态可查）

声明式模型：在路由配置的 meta 中声明该路由的权限要求——Vue Router 的 meta: { requiresAuth: true, permissions: ['order:view'] }，React Router 6+ 用 loader/自定义属性或在路由对象挂 permissions 字段；守卫统一入口（Vue 的 beforeEach、React Router 的 loader/route guard）读取 meta 校验：未登录→登录页、有码→放行、无码→403/无权限页。工程价值：权限声明与路由定义同处一地，静态可查可审（无需翻业务代码找权限判断）、增删路由时权限要求不会遗漏；守卫集中处理"进入前校验"语义，避免每个页面组件各自写权限逻辑；配合 meta 还可声明布局（layout）、标题、缓存（keepAlive）等，形成路由元数据体系。边界：meta 声明只解决"页面级"，按钮/数据级仍需组件内检查；meta 中不要放敏感逻辑（可被前端修改，仅作渲染决策）；React Router 6+ 的 loader 在渲染前执行，天然适合做权限校验与数据预取，失败时 throw 由 errorElement 承接降级。

本题考察声明式权限路由的工程实践。答题核心是 meta 声明模型与守卫统一校验的价值（静态可查、入口集中），以及它与组件级检查的分工与 React loader 的特殊用法。

• 权限变更的触发源（后台改权限、多端登录、管理员操作）
• 通知机制选型（WebSocket/SSE、轮询、请求响应头携带）
• 变更处理（刷新权限缓存、清理本地状态、强制重登）

触发源：管理员在后台修改用户角色/权限、多端登录同一账号、租户策略变化；前端需在这些场景下刷新权限数据与界面。通知机制选型：WebSocket/SSE 适合实时性要求高的内部系统（后台推送"权限已变更"事件，前端收到后重新拉取权限树并刷新菜单/按钮/路由守卫缓存）；轮询（定时拉取 /me/permissions 或权限版本号）实现简单、适合低频变化与无法长连接的场景；更轻量的做法是"响应头携带版本"——每次 API 响应带 permission-version 头，前端发现版本变化即重新拉取（顺带解决"请求过程中权限已变"的一致性问题）。变更处理：重新拉取后刷新内存缓存与 store、重新计算菜单与按钮显隐、对已打开页面做路由重校验（无权限则跳转/提示）、敏感操作强制重登；边界：前端收到通知到生效有窗口期，关键操作仍以服务端校验为准；通知通道不可用时（断网）依赖请求时校验兜底。

本题考察权限动态化的工程实现。答题核心是"触发源识别 + 通知机制选型（推送/轮询/版本头）+ 变更处理流程"以及"服务端校验永远兜底"的边界认知。

• 持久化载体选型（localStorage/sessionStorage/内存+请求）
• 刷新恢复与重登清理的生命周期管理
• 变更同步（版本号、事件驱动、重新拉取）策略

持久化选型：sessionStorage 适合会话级（刷新保留、关标签清空，多标签安全）；localStorage 跨会话保留但有过期与多标签同步问题；纯内存 + 启动时请求是"最安全"（不落盘）但刷新要重新请求（可配合缓存）。实践组合：内存 store 为主（响应式驱动 UI），持久层按安全等级选择——低敏场景 sessionStorage 快恢复，高敏场景（金融）不落盘、刷新后重新拉取。刷新恢复：应用启动先读持久层或请求 /me 接口拿用户与权限，再生成菜单与路由；恢复过程要有 loading 态，避免闪 404。重登清理：登出时清除权限缓存与本地数据、重置 store、跳登录页；多端登出（服务端吊销）靠请求 401 拦截触发。变更同步策略：权限版本号对比（响应头/通知带版本，前端版本落后则重新拉取）、事件驱动（通知通道推送后刷新）、定时兜底（低频轮询）；拉取与渲染要做防抖避免频繁刷新 UI。

本题考察权限数据生命周期的完整设计。答题核心是"持久化选型的安全权衡、刷新恢复流程、登出清理"以及"版本号/事件/轮询"三层同步策略。

• 微前端间登录态与用户信息的共享机制（基座注入、全局状态）
• 子应用路由与权限的独立/统一校验
• 权限数据共享与隔离的边界（公共权限 vs 应用私有）

协作模型：登录态共享——基座统一处理登录（OAuth 流程、Token 刷新），把用户信息与 Token 通过 props/全局 store/自定义事件注入子应用，子应用不再各自登录；权限数据共享——基座拉取用户权限树放入全局 store（如 qiankun 的 globalState、Module Federation 的 shared store），子应用按需读取公共权限（菜单、公共按钮）做渲染，私有权限（应用特有资源）由子应用自行请求其后端校验。路由与守卫：基座管全局路由（登录、404、权限不足页），子应用管业务路由；子应用路由守卫校验时可读取注入的权限上下文，但鉴权仍以其后端为准。隔离边界：身份（userId/token）共享但密钥（刷新 token）不共享；权限数据按"公共/私有"分域，子应用不能修改基座注入的数据（只读引用）；子应用间权限互不可见（不把 A 的权限列表暴露给 B）；沙箱内子应用的 localStorage 命名空间隔离，避免权限缓存串扰。

本题考察微前端权限架构。答题核心是"基座统一身份、全局状态共享公共权限、子应用私有权限自治"的三层模型，以及共享与隔离边界的明确划分。

• JWT 三段结构（header/payload/signature）与签名原理
• 前端解码 payload 的可行性与不可信性
• 安全边界（不验签不解密、过期/撤销、敏感信息不入 token）

JWT 由 header（算法、类型）、payload（claims：sub、exp、iat、自定义权限字段）、signature（header+payload 用密钥/私钥签名）三段 Base64 组成；签名保证"未被篡改"，payload 本身只编码不加密，任何人都能 Base64 解码查看。前端可以解码 payload 读取权限 claims（用于渲染 UI 与本地判断），但存在安全边界：前端无法验证签名（验签需密钥，只能放服务端），解码出的内容不可信——攻击者可伪造本地解码结果，因此前端读取的权限只能用于"展示层"；敏感信息（密码、密钥、完整用户资料）绝不能放入 token（会被任何人看到）；前端判断过期用 exp 但不依赖它（时钟偏差、篡改）；权限撤销无法通过 JWT 本身实现（无状态 token 撤销困难），需短过期 + 刷新令牌（refresh rotation）、黑名单或权限版本号；算法安全上服务端应限定 alg（防 none 与混淆攻击）。核心原则：token 是"身份凭证+轻量声明"，权限的最终裁决永远在后端。

本题考察 JWT 的底层机制与前端使用边界。答题核心是"payload 可解码不可验签→前端只用于 UI、裁决靠后端"，以及撤销难题（短过期+旋转）与敏感信息不入 token 等安全实践。

• RBAC 模型（用户-角色-权限）与前端数据形态（角色集合/权限集合）
• 菜单与路由基于角色的过滤与渲染
• 角色变更、角色继承与权限计算的边界

RBAC 核心是"用户-角色-权限"三层：用户被分配角色，角色拥有权限集合，权限与资源（菜单、路由、按钮、接口）绑定；前端对接形态通常是后端返回"用户角色集合 + 合并后的权限集合"（或按角色下发），前端以权限集合驱动渲染，避免前端做多角色权限并集运算。工程落地：菜单——后端按用户角色裁剪菜单树返回，前端递归渲染；路由——路由 meta 声明角色/权限要求，守卫校验当前用户角色/权限；按钮——v-permission 指令按权限集合控制。边界与注意点：多角色用户取并集（任一角色拥有即放行）且界面标注角色来源；角色变更（新增/移除角色）要触发权限数据刷新；角色继承（部门角色继承）建议由后端计算展开后返回，前端不做推理；权限集合为空时默认拒绝（白名单路由除外）；避免把"角色"硬编码进前端逻辑（角色名会变），以权限码为准。RBAC 粒度不足的场景（数据级、环境条件）用 ABAC 补充。

本题考察 RBAC 的前端落地。答题核心是"后端算好权限集、前端按集合渲染"的对接模型、meta 声明与守卫校验，以及角色并集、默认拒绝与以权限码为准的工程原则。

• Feature Flag 的定位（功能发布、灰度放量、开关）
• 权限系统的定位（资源授权、身份相关、安全相关）
• 结合模式：灰度标志按用户分桶、功能权限与灰度叠加决策

本质区别：Feature Flag 是"功能可见性"控制——面向发布节奏，决定"这个新功能哪些流量/用户能看到"，目标是灰度放量、快速回滚，判定依据是分桶（用户 id 哈希、地域、百分比）、与安全无关，通常由发布/配置中心管理；权限系统是"资源授权"控制——面向访问安全，决定"这个用户能否操作某资源"，判定依据是身份与角色权限，直接关系安全，由鉴权体系管理。二者易混淆但语义不同：flag 说"你能不能用这个新功能"，权限说"你有权执行这个操作"。结合模式：按用户——功能 flag 先按白名单/百分比放量，命中者叠加其原有权限做最终渲染（flag 通过 且 有权限 才展示），未命中者直接走旧功能；按灰度——灰度分桶结果随请求传递（header/参数），前端与后端共用同一分桶算法保证一致性，后端在 flag 放行基础上再做权限校验；权限系统也可借用 flag 机制做"功能级授权"（如套餐门控），但要与安全权限分离治理。

本题考察两个易混概念的本质区分。答题核心是"发布节奏 vs 安全授权"的定位差异，以及"flag 分桶 + 权限校验"叠加决策的两种结合模式与前后端一致分桶。

• 套餐门控的数据模型（plan、features、limits）与下发
• 前端按套餐渲染/禁用/升级引导
• 门控与硬限制（额度）的后端强制校验分工

套餐门控模型：后端定义套餐（plan）→ 功能特性（feature flag 化：高级报表、API 导出）→ 用量限额（limits：项目数、成员数、调用量）；用户登录后后端返回其套餐与可用特性/限额，前端 SDK（或 API 响应）驱动 UI：无权限特性隐藏或加锁（展示升级入口与对比表）、限额接近用尽时提示与升级引导（硬升级墙）。分工原则：门控分两层——"功能可用性"（这个套餐能不能用该功能）前端可按套餐数据渲染（体验层）；"硬约束"（额度是否允许本次操作）必须后端校验——接口按套餐校验并返回 403/429/额度不足错误码，前端展示对应文案；前端不能信任套餐数据做安全判断（用户可篡改本地），改套餐后权限数据刷新重新渲染。工程要点：套餐特性字典与前端功能点映射集中管理（feature 枚举）、限额在 UI 实时展示（剩余配额）、降级套餐时提示受影响功能与过渡期、license 校验（企业版离线场景）用签名授权文件验签后启用。

本题考察商业化功能门控的设计。答题核心是"套餐-特性-限额"模型与"前端渲染门控、后端硬校验额度"的分工，以及套餐变更刷新与签名授权等边界。

• 权限变更后已渲染页面的失效场景（角色被回收、被降级）
• 处理手段：路由重校验、数据重取、403 拦截、强制登出
• 长会话（无感续期）下的定期重校验与事件驱动刷新

已打开页面的失效处理分三档：轻量——重新拉取权限数据后重算菜单/按钮显隐（不打断用户）；中等——对当前路由重校验，无权限则跳转 403/首页并清理该页缓存；强力——涉及敏感数据/安全事件时强制登出（清除会话、跳登录并携带原因）。数据层面：接口 403 拦截器统一处理——刷新 token 重试一次、仍失败则清理权限缓存并触发页面失效流程；已展示的数据在权限回收后应被"重新拉取验证"（防陈旧数据越权展示）。长会话策略：长会话（refresh token 无感续期）下权限会随时间变化，需要定期重校验——定时器/空闲恢复时拉取权限版本号、路由激活时（keep-alive 页面重新激活）重校验、关键操作前校验；配合服务端主动推送（WebSocket 权限变更事件）即时失效；多标签页用 storage 事件同步权限变更。核心原则：权限失效要"可感知、可恢复"——给用户明确反馈（无权限提示）与恢复路径（重新登录/联系管理员），避免静默失败。

本题考察权限动态性的完整治理。答题核心是"轻量刷新/路由重校验/强制登出"三档失效处理、403 拦截与数据重取，以及长会话下的定期重校验与事件驱动刷新。

• meta 权限字段的设计（roles/permissions/自定义校验函数）
• 守卫中的统一读取与决策逻辑
• 字段演进与多条件组合（任一/全部/自定义）的实践

设计要点：meta 中声明 meta.permissions（权限码数组）与 meta.roles（角色数组）表示"访问要求"，语义约定——数组内为"任一满足"（OR），需要"全部满足"（AND）或复杂条件（时间窗口、环境）时提供 meta.authority 函数（接收用户上下文返回布尔），保持声明可序列化优先、函数兜底复杂场景。守卫统一逻辑：beforeEach 中读取 to.meta，先判登录（requiresAuth）→ 再判权限（无 meta 声明视为公开路由）→ 不满足则重定向（登录页/403/上一页）；权限校验函数集中（utils/hasPermission）避免各路由自行实现。最佳实践：字段命名统一并生成 TS 类型（路由 meta 类型扩展）、公开/白名单路由显式声明（或默认公开）、父子路由 meta 合并语义（子路由继承父级要求需明确）、meta 不承载敏感校验逻辑（可被修改，仅渲染层）；配合组件级 meta 读取（面包屑、标题、缓存开关）形成路由元数据体系。React Router 6+ 无 meta 概念，可在 route handle 或自定义字段声明并由 loader/自定义 hook 读取。

本题考察路由权限声明的规范化。答题核心是"任一/全部/函数"三种表达的设计与守卫统一决策，以及类型化、继承语义、公开路由等最佳实践。

• beforeLoad 的执行时机（渲染与数据加载前）与 API
• 在 beforeLoad 中做权限校验与重定向（throw redirect）
• 与 loader（load）数据预取的编排（校验失败不加载）

TanStack Router 中 beforeLoad 是路由进入前的钩子，在组件渲染与 load（数据加载）之前执行，天然适合权限校验：在 beforeLoad 内读取当前用户与权限上下文，无权限时 throw redirect({ to: '/403' }) 或 throw notFound() 终止导航；beforeLoad 的 context（从父路由继承注入的 loaderContext）可携带鉴权服务（authStore、permissions），子路由共享。配合要点：权限校验放在 beforeLoad 而不是 load——校验失败直接终止，避免无权限时仍发起数据请求；load 只负责数据预取（可依赖 beforeLoad 已确认的权限决定取什么数据）；beforeLoad 可做异步（等待权限数据就绪）；匹配器（routeMatch）层面的 preload 与 beforeLoad 的时序要理解（preload 在 hover/预取时也会触发 beforeLoad，需避免副作用）；错误处理用 errorComponent/notFoundComponent 承接。该模式与 Vue Router 守卫等价，但类型安全（context 类型推导）与取消（loader 可中止）更现代。

本题考察现代路由库的权限实践。答题核心是 beforeLoad"渲染与加载前执行、throw redirect 终止"的语义及其与 load 的分工（校验在前、取数在后），体现对 TanStack Router 执行模型的理解。

• loader 的渲染前执行语义与 throw 机制
• 在 loader 中校验权限并 throw redirect/Response
• 与 errorElement、useRouteLoaderData 的配合及注意事项

React Router 6+ 的 loader 在路由组件渲染与数据加载前执行，返回值注入组件（useLoaderData），权限校验可放在 loader 中：读取用户上下文（从 context/自定义 store），无权限时 throw redirect('/403') 或 throw new Response('Forbidden', { status: 403 })，由 errorElement/边界承接渲染 403 页；校验通过后继续返回页面数据，实现"校验+取数"一次完成。工程价值：路由级声明式校验（每个路由的 loader 自带权限逻辑）、渲染前拦截（无权限不渲染组件、不发无效请求）、与数据加载统一编排（权限决定取哪些数据）。注意点：loader 在客户端导航与预取（link prefetch）时都会执行，副作用需谨慎（不要在 loader 中做非幂等操作）；loader 中访问的权限上下文需通过 RouterProvider 的 context 或模块级 store 注入（不能直接用组件 hook）；401/403 需区分处理（401 跳登录、403 跳无权限页）；并行路由（layout 路由）的 loader 都会执行，权限校验层级设计要清晰（layout loader 校验整体访问、子 loader 校验页面数据）。

本题考察 React Router 现代数据 API 的权限用法。答题核心是"loader 渲染前执行 + throw redirect/Response"的校验模式与 errorElement 承接，以及预取副作用与层级校验等注意点。

• 懒加载的动机（权限数据大、多租户、低频模块）
• 按需加载的实现（路由级/模块级拉取）与缓存
• 边界：首屏体验、离线、权限变更一致性

动机：大型系统权限树庞大（上千菜单/按钮）、多租户差异化配置、大量长尾模块低频使用，全量预取浪费带宽与首屏时间。懒加载实现：登录后只拉取"当前用户首页/一级导航所需权限"，进入具体模块时按模块 code 拉取该模块菜单与按钮权限（接口 /permissions/module/:code），结果缓存（内存+版本号）；菜单骨架先渲染，权限数据到达后再填充。边界与代价：懒加载引入异步缺口——模块页面可能先渲染后补权限（闪烁、按钮短暂可见），需 loading 骨架与"默认拒绝"策略（数据未到前不显示敏感按钮）；离线/弱网下模块权限拉取失败需降级（缓存兜底或提示）；权限变更一致性更难保证（按需缓存分散，需要统一的版本号失效机制）；守卫与渲染都要支持异步权限（await 权限就绪再放行）。取舍建议：核心高频模块与首屏菜单全量预取（体验优先），低频后台模块懒加载（性能优先），用"首屏全量 + 深层懒加载"混合模式，并用版本号统一失效。

本题考察权限加载策略的权衡。答题核心是懒加载的动机与"模块级拉取+缓存"实现，以及默认拒绝、异步缺口、版本失效等边界治理，给出混合加载建议。

• 静态路由表 + 动态添加路由（addRoute）的实现
• 路由与菜单、权限的统一数据源设计
• 动态路由的边界（深链接刷新、权限变更、类型安全）

经典实现：项目维护"基础路由"（登录、404、403）静态注册，"业务路由"以配置形式（meta 含权限码）存放在前端或由后端返回，登录后按用户权限过滤得到可访问路由集合，再动态注册——Vue Router 4 用 router.addRoute()，React Router 用路由数组 state 动态渲染（无需 addRoute）。统一数据源：路由配置与菜单配置同源（一份 schema 同时生成菜单树与路由表），权限码声明在配置中，过滤逻辑集中（filterRoutesByPermissions）。现代实践与边界：深链接刷新——页面直接刷新时权限可能尚未就绪，需在全局前置守卫中"等待权限+动态路由就绪"再放行（否则刷新 404）；权限变更——重新过滤并重注册路由，同时清理已注册的动态路由（removeRoute），避免旧路由残留；类型安全——路由配置生成类型（route meta 类型、params 类型），用工厂函数而非手写对象；静态路由与动态路由命名冲突规避；动态注册的路由要配合菜单高亮（activeMenu）与面包屑映射。复杂度可控时也可全部静态注册 + 守卫按权限放行（简单系统更稳），动态生成适合权限差异大的系统。

本题考察动态路由的完整实现。答题核心是"权限过滤 + 动态注册"与"菜单/路由同源"的设计，以及深链接刷新等待、权限变更重注册、类型安全三大边界。

• OPA 的架构（策略即代码、集中决策、Rego 语言）
• 前端与 OPA 的交互方式（决策 API、SDK 查询）
• 边界：前端不可直接信任 OPA 决策、性能与离线场景

OPA 是开源的策略引擎：策略用 Rego 声明式语言编写（解耦"策略"与"应用代码"），通过 REST 决策 API（POST /v1/data/{path}）或 SDK 嵌入方式提供授权决策；Rego 支持 RBAC/ABAC 混合规则、数据（用户属性、资源属性、环境）与策略分离，适合复杂多变的授权规则集中治理。前端与 OPA 的边界：前端不能把 OPA 当"安全边界"——OPA 决策若在前端执行（SDK 内嵌、本地规则），其输入可被篡改，只能用于展示层；正确做法是后端鉴权中间件调用 OPA 决策，前端仅消费"已授权"结果（如后端返回的权限视图），或前端仅用于实时渲染增强（查询"当前用户对当前资源的操作是否允许"提升交互，但最终以服务端为准）。其他边界：决策 API 有网络延迟（前端直查需缓存与降级）、离线不可用、Rego 查询的输入 schema 需与后端一致（避免前端传参口径不同导致决策漂移）；策略版本化与灰度（策略变更先小流量）需要后端运维支持。结论：OPA 是后端策略中台，前端只做"决策结果的友好呈现"。

本题考察 OPA 的架构定位。答题核心是"策略即代码、集中决策"的价值与"前端不可信、决策归后端、前端消费结果"的边界，以及性能与离线约束。

• 后端权限接口的拆分形态（统一 /permissions vs 分层接口）
• 权限数据模型（菜单树、按钮码、数据权限分开建模）
• 前端消费模式（按模块拉取、增量更新）与拆分边界

后端 API 设计两种形态：统一接口——GET /permissions 返回完整权限包（菜单树 + 按钮码 + 数据权限范围），简单直接，适合中小系统；分层接口——GET /menus（菜单树）、GET /permissions/buttons?module=xxx（按钮码）、GET /data-scopes（数据范围），适合权限数据大、模块差异大的系统，配合按需拉取与缓存。数据模型拆分原则：菜单权限（页面级可见性）、按钮权限（操作级控制）、数据权限（行/字段级范围）三者建模分离（不同表/不同字段），避免混在一个 JSON 里导致前端解析耦合；菜单树含路由信息、按钮码按模块分组、数据范围返回规则（如 deptIds/ownerOnly）。前端消费：登录拉取菜单树（渲染导航）、模块进入时拉按钮码（渲染操作区）、请求列表时携带数据范围参数；增量更新（权限变更推/拉局部刷新）。拆分边界：按钮权限粒度到"操作"，但"字段级"权限（表单字段显隐）应单独建模（字段配置接口），别塞进按钮权限；菜单权限决定路由可达性，与按钮权限是"页面进入 vs 页面内操作"的两层，后端接口校验也按这两层分别 enforce。

本题考察权限接口的工程建模。答题核心是"统一 vs 分层"接口形态的取舍、菜单/按钮/数据三级权限的分开建模，以及前端分层消费与字段级权限独立建模的边界。

• ReBAC 的核心（对象-关系-用户的关系图建模）
• Zanzibar 的架构特点（关系元数据、大规模一致、增量更新）
• 前端消费关系判定结果的模式与边界

ReBAC 把授权建模为关系图：节点是对象（文档、文件夹、组织）与主体（用户、组），边是关系（owner、editor、member），授权判定即"用户经关系图是否可达目标对象与所需关系"（如"用户 A 是否对文档 D 有 editor 关系"），天然支持资源归属、组织层级、共享等复杂场景，是 Google Zanzibar（及 OpenFGA、SpiceDB 等开源实现）采用的模型。Zanzibar 风格要点：关系元数据（relation tuples）与数据分离、水平扩展支持大规模、基于版本（zookie）的一致性读取、增量变更同步；判定 API 返回布尔或关系展开结果。前端应用边界：前端不直接读关系图（不可信），而是调用后端判定接口（check API：用户/对象/关系）获取结果用于 UI 渲染（按钮显隐、分享面板、级联授权提示）；需要批量时用 expand/batch check；关系变更（被移出项目、分享撤销）通过 WebSocket/轮询通知前端刷新；离线与性能上判定结果要缓存并按 zookie/版本失效；前端也可借助关系图做体验增强（级联选择"继承权限"、显示共享来源），但安全判定始终后端。

本题考察现代授权模型。答题核心是"关系图建模"与 Zanzibar 的规模一致性特点，以及"前端消费 check 结果、判定归后端"的应用边界。

• 401（未认证/过期）与 403（无权限）的语义差异
• 统一拦截器的分流处理（刷新重试、跳登录、跳无权限页）
• 提示设计（Toast、404 伪装、升级引导）与防循环

语义区分：401 表示"身份无效或过期"（未登录、token 失效），处理路径是刷新 token 重试一次，仍 401 则清会话跳登录页（携带 redirect 参数回跳）；403 表示"已认证但无权限"，处理路径是提示无权限并跳转 403 页面或停留在当前页禁用操作，绝不能当 401 处理（会导致登录死循环）。工程实践：统一请求拦截器（axios/fetch wrapper）按 status 分流——401 走刷新队列（并发 401 合并刷新一次）+ 重试 + 失败跳登录；403 区分"页面级"（路由守卫已拦）与"接口级"（组件内局部提示，不跳整页）；提示设计：页面级 403 展示友好页（带返回首页、联系管理员入口），接口级 403 用轻提示（Toast/Inline 错误），敏感资源可用"404 伪装"（避免暴露资源存在性）；防循环：登录页与 403 页自身请求不能触发拦截、刷新 token 失败次数上限、跳转带来源标记避免回跳死循环；权限提示应给出"为什么没有权限 + 怎么办"（升级套餐、申请权限入口）。

本题考察鉴权失败的 UX 与工程处理。答题核心是 401/403 语义差异与分流处理链路（刷新重试/跳登录/无权限页）、提示分层设计与防循环机制。

• 权限点字典的跨端统一（同一 key、同一语义）
• 多端消费差异（Web 渲染层 vs 原生控件、小程序）
• 一致性保障（字典版本化、服务端下发、端上缓存同步）

复用前提是"权限点字典唯一"：权限点（如 order:export）在权限管理平台集中定义，Web、App、小程序共用同一套 key 与语义（由服务端统一管理，各端从同一接口拉取），避免各端自造 key 导致同名不同义。多端消费差异：Web 用指令/组件/Hook 控制 DOM 显隐；App（原生/RN/Flutter）用权限 SDK 判断后控制控件渲染与原生能力（分享、相机）；小程序用条件渲染与按钮权限组件；各端实现不同但都只依赖"权限点集合"这一数据契约。一致性保障：权限点字典版本化（新增/废弃走评审，废弃的 key 有迁移期）；端上缓存带版本号，服务端权限变更推送后各端按版本失效重拉；后端接口按权限点统一 enforce（多端共用后端，天然一致）；权限点命名规范（模块:资源:动作）防重复；跨端差异场景（同 key 不同端行为不同，如 Web 可导出、App 需升级版本才可导出）由特性开关叠加权限点表达。治理上做权限点覆盖率审计（无主/重复权限点清理）。

本题考察多端权限治理。答题核心是"权限点字典单源 + 各端按数据契约消费 + 版本化与推送同步"的一致机制，以及后端统一 enforce 的天然保障。

• ACL 模型（资源-权限-主体列表）与适用场景
• 数据级权限的实现（数据范围、行过滤、字段脱敏）
• ACL 与数据权限的组合（对象级授权 + 列表范围过滤）

ACL（访问控制列表）为每个资源对象维护"主体（用户/组）- 操作"列表，例如文档可被 {alice: read, bob: write, team: read} 访问，适合"对象级授权"场景（共享文档、项目空间、协作数据），授权粒度细、可显式管理；与 RBAC 的"角色-资源类别"不同，ACL 面向具体实例。数据级权限分两档：行级（数据范围）——用户只能看到符合范围的数据（本人创建、所属部门、指定 deptIds），常见实现是后端把数据范围规则翻译成 SQL 过滤条件（mybatis 拦截器/JPA 条件），前端传范围参数或由后端注入；字段级——敏感字段（手机号、金额）按权限返回脱敏或隐藏列。两者结合模式：ACL 管"这个对象你能做什么"（详情页操作），数据范围管"列表里你能看到哪些对象"（列表过滤），前端拿到"列表数据（已过滤）+ 对象级 ACL 结果（操作按钮显隐）"分层渲染；复杂场景（ACL 继承、权限传播）由后端计算拍平后返回，前端不推理。

本题考察对象级与数据级权限的体系。答题核心是 ACL 的对象-主体-操作模型、数据范围/字段脱敏的实现，以及"列表过滤 + 对象授权"分层结合的消费模式。

• 多对多模型（用户-角色、角色-权限）与前端数据形态
• 多角色下的权限合并（并集、优先级、冲突处理）
• 角色切换（impersonation）与角色上下文治理

数据模型：后端维护用户↔角色多对多、角色↔权限多对多，登录后返回用户的角色列表与"合并后的权限集合"（后端完成并集计算），前端通常只消费合并结果（permissions: string[]），避免前端重复实现集合运算导致口径漂移。多角色合并语义：默认取并集（任一角色拥有即授权）；需要优先级/互斥（如"审计角色"与"操作角色"并存时的行为差异）时，由后端按业务规则合并（返回最终权限集+角色标记），前端按业务规则响应（如显示角色标签、按角色切换工作台布局）。角色切换（同一用户多个身份/租户角色）：切换是"上下文变更"——切换后重新拉取该角色的权限集与菜单、刷新当前页面与缓存、清除旧角色状态，避免混用；权限变更/角色被移除的实时感知沿用版本号+通知机制。工程边界：前端不存"用户-角色-权限"全量关系表（数据属后端）；角色名仅用于展示，判断一律用权限码；多角色场景下"无权限=并集为空"默认拒绝。

本题考察多角色权限的前端模型。答题核心是"后端合并权限集、前端消费结果"的形态、并集/优先级语义与角色切换的上下文治理。

• OAuth 2.1 的主要收紧项（PKCE 必选、隐式流废弃、刷新令牌轮换）
• 前端授权码流（Authorization Code + PKCE）的实现
• SSO/IdP 场景下前端的登录态管理与登出（SLO）

OAuth 2.1 合并了 2.0 多年实践的安全改进：授权码流 + PKCE 成为必选（不再允许隐式流，前端单页应用必须走授权码流，code 交换 token 在带密钥的后端完成或采用 PKCE 无密钥交换）；刷新令牌必须轮换（每次刷新返回新 token，旧 token 失效，降低泄露窗口）；状态参数与精确重定向 URI 校验、禁用密码模式等。工程价值：前端不再"裸存 token 于 URL"，登录流程变为——跳转 IdP 授权（带 code_challenge），回调拿到 code，后端/PKCE 交换 token，前端安全持有并在续期时轮换刷新令牌。SSO 集成：多个系统共用 IdP 登录态（Cookie 会话 + 本地 token 双通道），前端处理"已登录其他系统"的静默 SSO（重定向带回 code）、单点登出（SLO：登出通知所有已登录系统）与多标签页同步（storage 事件）。边界：前端仍不可存密钥、token 存内存+短期（刷新靠轮换）、登出需清 IdP 会话不能只清本地。

本题考察现代认证协议在前端的落地。答题核心是 2.1 的安全收紧（PKCE 必选、令牌轮换）对前端流程的改变，以及 SSO 静默登录与 SLO 的实现要点。

• 多租户隔离模式（独立数据库、共享表+租户字段）对权限的影响
• 租户上下文的传递（token/header、路由参数）与前端管理
• 切换租户（多租户用户）的权限刷新与边界

多租户隔离模式：SaaS 常见"共享表 + 租户 ID 字段"（低成本、需每请求带租户上下文且 SQL 强制过滤）或独立 Schema/库（隔离强、成本高），权限模型在此之上：每个租户有自己的用户-角色-权限数据（角色模板可复制），跨租户数据访问必须禁止（后端在鉴权时校验"资源归属租户 == 当前租户"）。租户上下文传递：登录后服务端签发带租户标识的 token（claims 含 tenantId），前端从登录响应或 /me 获取当前租户并随请求头（X-Tenant-Id）携带，切换租户即切换上下文；前端管理：租户列表展示（多租户用户）、切换入口、切换后重新拉取该租户的权限树/菜单/主题（品牌配置常按租户）、清理上一租户缓存（localStorage 按租户分域或切换清空）、路由与面包屑刷新。边界：前端租户标识不可信（可被篡改），数据隔离由后端强制（所有查询带租户过滤、防越权枚举其他租户 ID）；单租户场景避免过度设计（不必要的切换逻辑），多租户场景要把"租户上下文"作为全局状态统一注入而非散落。

本题考察多租户权限的架构。答题核心是隔离模式对权限数据的影响、租户上下文的全链路传递与切换刷新，以及"后端强制隔离、前端只做上下文管理"的边界。

• Casbin 的 PERM 模型（Policy/Effect/Matcher/Request）与 RBAC+ABAC 表达
• 决策 API 与前端消费（模型文件在后端、前端拿结果）
• 混合模型的边界（策略集中管理、前端只读结果）

Casbin 用 PERM 模型表达授权：Request（请求参数：主体、对象、动作、属性）、Policy（策略规则表，可含角色层级与属性条件）、Matcher（匹配表达式，如 r.sub == p.sub && r.obj == p.obj && r.act == p.act，可混入 ABAC 属性条件如 r.department == p.department）、Effect（最终效果：allow/deny 组合）。混合模型即"角色做主体分组 + 属性条件做细粒度约束"，一份模型文件同时支持 RBAC（角色继承 g 规则）与 ABAC（对象/环境属性匹配）。前端应用：Casbin 决策引擎运行在后端（模型/策略文件管理在服务端），后端对每个请求调用 e.Enforce(...) 决策；前端不直接运行 Casbin（策略模型是服务端资产），而是消费决策结果——后端返回"权限视图/按钮结果"或提供决策查询接口（前端传当前用户+资源+动作，后端返回 allow/deny 用于 UI 渲染增强）。边界：前端传参的决策查询仅用于展示（可篡改），关键操作仍由后端 Enforce；属性数据（部门、密级）以后端数据为准，前端不传关键属性；策略变更（模型文件/策略表）由后端发布，前端按权限版本刷新缓存。

本题考察主流策略引擎的集成模式。答题核心是 PERM 模型如何同时表达 RBAC+ABAC、决策必须在后端执行，以及前端只消费决策结果与版本刷新的边界。

• 前端可绕过点（篡改请求、修改本地状态、调用隐藏接口）
• 典型攻击路径（越权 IDOR、接口枚举、参数篡改）
• 纵深防御设计（后端校验、最小数据、审计）

白盒测试视角下前端一切防护都可被绕过：代码可读（压缩混淆只增加成本）、本地状态可改（localStorage 权限标记、内存对象）、请求可构造（浏览器 DevTools/脚本直接发请求）。典型风险：越权 IDOR——直接改请求中的资源 ID 访问他人数据（后端未校验归属）；接口枚举——隐藏接口可被直接调用（前端隐藏不等于不可达）；参数篡改——修改金额、角色、分页等参数；重放攻击——重复提交订单/验证码。防范设计（纵深防御）：后端所有接口独立鉴权（身份+资源归属+操作权限），不依赖前端传参决定权限；权限数据最小化（后端只返回有权限的数据，防前端枚举利用）；请求完整性（签名/HMAC 校验关键参数、防重放 nonce）；错误信息不泄露（403 不暴露资源存在性）；关键操作服务端挑战-响应（二次确认）；安全测试（白盒审计、越权用例自动化、依赖扫描）；前端侧尽量增加绕过成本（不暴露敏感逻辑、混淆仅作第一层），但明确"前端安全=0 纵深"的理念，防护重心始终在后端。

本题考察安全测试视角的威胁模型。答题核心是列举前端可绕过的具体攻击路径（IDOR、枚举、篡改、重放），并给出后端纵深防御与最小数据的设计原则。

• 权限矩阵（角色×权限二维表）的表达与审查价值
• 权限依赖图（路由/组件/接口的权限引用关系）
• 可视化的治理应用（权限评审、收敛、最小化）

权限矩阵把"角色×权限"组织成二维表（单元格=允许/拒绝/继承），价值在于：权限评审与新人理解（一眼看出角色差异）、发现冗余角色（两列完全相同的角色可合并）、发现越权风险（高权限角色权限过宽）与权限收敛（无主权限点）。权限依赖图把代码中的权限引用可视化——路由 meta、组件指令、接口注解中的权限码与其定义、被引用位置的关系图，价值：重构安全（改权限码时知道影响面）、发现孤儿权限（定义了但无引用）与幽灵引用（引用了不存在的码）、支撑最小化（删减长期未用的权限）。构建方式：权限矩阵由后端权限数据自动生成（权限管理平台报表）；依赖图由静态分析生成（扫描代码中权限码字符串常量与路由配置，构建引用图）。使用流程：发布评审时用矩阵核对角色变更影响、用依赖图检查权限码一致性；定期做权限健康度报告（冗余角色、孤儿权限、越权角色 Top）。边界：可视化是"治理工具"而非"安全机制"，矩阵/图表与实际决策无因果，最终以策略引擎为准。

本题考察权限治理的数字化手段。答题核心是矩阵与依赖图各自的审查价值、自动生成方式，以及权限评审与收敛的使用流程。

• 四层权限（路由/菜单/按钮/字段）的组件化表达
• 组件设计（指令、包装组件、Hook、上下文）与统一权限源
• 复用与扩展（权限组件库化、自定义策略注入）

分层设计：路由层——路由表 + 守卫（或 loader）控制页面可达性；菜单层——菜单树渲染组件消费过滤后的数据（后端裁剪或前端按权限集过滤）；按钮层—— 包装组件 / v-permission 指令 / usePermission Hook，无权限渲染占位（null/禁用/升级引导）；字段层——表单字段显隐/脱敏（ 或字段配置驱动，敏感字段展示掩码）。协作架构：所有层共享"统一权限源"（全局 store 中的权限集合与用户上下文），组件从 store 读取而不是各自传参；权限判断收敛为 usePermission(code) 一个入口（内部处理数据未就绪的默认拒绝）；权限变更时 store 更新驱动各层自动重渲染。复用与扩展：把四层封装成"权限组件库"（跨项目复用），支持自定义渲染策略（hide/disable/upgrade）注入、支持异步权限（数据未到先 loading）、类型安全（权限码枚举）；注意组件库不绑定具体权限源（通过 provider 注入），后端数据格式变化时只改适配层。

本题考察权限 UI 的组件工程。答题核心是四层权限的组件化表达与"统一权限源 + 单一判断入口"的协作架构，以及组件库化的复用与策略注入。

• SemVer 语义（major/minor/patch）与破坏性变更规范
• Changesets 的工作流（变更集、自动版本、CHANGELOG、发布）
• 发布工程（CI 流水线、canary/next 通道、依赖升级策略）

SemVer 规范：major 破坏性变更（API 移除、默认行为变化）、minor 新特性（向后兼容）、patch 修复（向后兼容），组件库必须严格执行——使用者按版本号判断升级风险；破坏性变更要有迁移指南与 codemod（自动迁移脚本）。Changesets 工作流：开发者改动时写 changeset 文件（描述变更与影响包），CI 校验；发布时 changesets 自动计算新版本（按 changeset 的 major/minor/patch 类型）、生成 CHANGELOG、提交版本 bump 并发布 npm；支持多包（monorepo）独立版本与"只发有变更的包"。发布工程要点：CI 流水线（lint/type/test/构建产物检查后发布）；发布通道——latest 正式版、next/canary 预发布（供早期使用者验证）、alpha 内部；发布后更新依赖方（下游项目用 renovate 自动升级并跑测试）；产物校验（发布的包内容白名单：仅 dist、类型、README，防源码/测试泄露）；版本一致性（peerDependencies 范围、tokens 与组件同版本或独立版本但锁定）。

本题考察组件库发布工程。答题核心是 SemVer 的破坏性变更纪律、Changesets 的自动化工作流（变更集→版本→CHANGELOG→发布），以及 CI 与多通道发布的工程要点。

• 三类组件的定义与依赖关系（基础→布局→业务）
• 分层架构的收益（复用、稳定 API、独立发布）
• 分类边界（混合组件、跨层依赖治理）

分类架构：基础组件（Button、Input、Modal 等原子级，无业务语义，API 稳定）；布局组件（Layout、Grid、Container 等页面骨架，组合基础组件）；业务组件（UserCard、OrderTable 等带业务语义，依赖基础/布局组件与业务数据）。依赖方向单向：业务→布局/基础，布局→基础，基础不依赖上层；API 稳定性从基础到业务递减，业务组件迭代快。工程价值：分层使复用边界清晰（跨项目复用基础库、业务组件按业务域复用）、发布节奏可分离（基础组件低频发布需严格 SemVer，业务组件高频）、设计系统落地有载体（tokens 属于基础层）；也便于权限/主题/无障碍策略在基础层统一实现。分类边界与治理：组件可能跨类（如既算基础又是业务，如带权限的 Button 应属"业务扩展基础"）；跨层依赖纪律用 lint 约束（eslint import 限制：业务层不得被基础层引用、布局层不得依赖业务组件）；分类服务于可维护性而非教条，混合组件通过"基础组件 + 业务组合"拆分或归类到组合层；目录与文档按分类组织，组件元数据（category 字段）驱动文档站分组。

本题考察组件库的分层架构。答题核心是三类组件的定义与单向依赖、分层带来的复用/发布/设计系统价值，以及跨层依赖治理与混合组件的边界处理。

• Design Tokens 的分层（基础/语义/组件级）与格式（W3C DTCG）
• Figma 到代码的同步机制（Tokens Studio、插件、自动生成）
• 同步的工程边界（人工审查、版本化、主题多品牌）

Token 体系分层：基础 token（颜色、间距、字号等原始值，如 color.blue.500）；语义 token（映射业务语义：color.background.surface、spacing.md，主题切换时只改映射）；组件级 token（组件内部引用语义 token）。格式建议 W3C DTCG 标准（JSON 结构化、支持主题与别名），由单一仓库管理，构建时生成各端产物（CSS 变量、SCSS、TS 常量、Android/iOS 资源）。Figma 同步：设计侧用 Tokens Studio 等插件把 token 以 JSON 导出到代码仓库（或从仓库同步到 Figma，双向往返）；工程侧 CI 校验 token 变更（命名、引用完整性、对比度）后自动生成样式文件并发布版本；组件库通过 token 版本锁定（组件升级与 token 升级联动）。边界与治理：自动同步不等于免审查——token 变更影响面大（品牌视觉、无障碍对比度），需设计评审与可视化 diff（生成的 token 报告/截图对比）；主题多品牌通过"多套语义 token 映射"实现，运行时切换（data-theme）；token 命名规范防滥用（禁硬编码颜色值，lint 检查样式文件）；同步冲突（设计师改 Figma 与开发改代码）用 git 级 token 仓库解决，或选定单向权威源（通常代码仓库为权威，Figma 只读）。

本题考察设计系统的工程化核心。答题核心是"基础/语义/组件"三层 token 模型与 DTCG 格式、Figma↔代码的双向同步机制，以及评审、多主题与命名治理的边界。

• ESM 模块化与 sideEffects 声明对 Tree Shaking 的影响
• 按需加载的实现（子路径导入、babel-plugin、CSS 拆分）
• 打包产物设计（esm/cjs、入口粒度、样式导入）与验证

Tree Shaking 的前提是模块系统可静态分析：组件库发布 ESM 产物（module 字段指向 esm 入口）、源码保持 ESM 且无运行时副作用，package.json 声明 "sideEffects": ["*.css"]（告诉打包器只有样式有副作用可安全摇树），避免在模块顶层执行副作用代码（全局注册、样式副作用混淆）；单文件单组件导出，避免"index 汇总文件"里统一导出造成连带打包。按需加载：提供子路径导入（import { Button } from 'lib' 时打包器按 ESM 静态分析自动摇树，或 lib/button 子路径直接导入单组件）；旧方案 babel-plugin-import 做语法转译（自动改写为子路径+样式导入）适用于 CJS 老库；样式按组件拆分（每个组件独立 css 文件，支持按需引入或 CSS-in-JS/vanilla-extract 零运行时方案）。产物设计：esm（现代打包）+ cjs（兼容）双产物、types 随行；组件级分包（每个组件独立 chunk）支持动态 import 懒加载；入口体积控制（基础样式与组件样式分离）。验证：用打包分析工具（webpack-bundle-analyzer）检查实际引入体积、CI 中对比"只引 Button"的产物字节数回归，防止某次改动破坏摇树。

本题考察组件库的构建优化。答题核心是 ESM+sideEffects 声明对摇树的前提、子路径/插件两种按需方案与样式拆分，以及产物设计与体积回归验证。

• 权限模型（操作权限）与数据模型（行/字段）的映射关系
• 数据级权限的协同机制（接口返回裁剪/规则下发、字段脱敏）
• 前端消费形态（列表过滤、字段掩码、详情校验）与边界

协同本质是"操作权限决定能不能做，数据权限决定能看到哪些数据、哪些字段"：操作权限（按钮/接口）控制动作入口，数据权限（数据范围、字段权限）控制数据面。协同机制两条路径：服务端裁剪——接口按用户数据权限直接返回过滤后的行与脱敏后的字段（推荐，前端不可信）；规则下发——后端下发数据权限规则（deptIds、字段掩码配置），前端结合列表渲染（用于减少无效请求与体验优化，安全仍靠服务端）。前端消费形态：列表接口已返回过滤后的数据（前端无需二次过滤）；字段级——敏感字段（手机号、身份证）按权限返回明文/掩码/不返回三态，前端按字段权限配置渲染（掩码展示、无权隐藏、点击申请解密）；详情页与导出操作按数据权限校验（详情行越权访问由后端拒绝）。边界：前端掩码只是展示层（接口已按权限处理），防绕过仍靠后端（请求未授权字段返回 403/空）；数据权限规则前端不可信（仅用于提示"列表不完整"）；字段权限变更（申请通过）实时刷新（版本号/通知）；协同模型需权限平台与数据字典联动（同一资源在权限树与数据字典中同一标识）。

本题考察权限与数据模型的协同。答题核心是"操作权限控动作、数据权限控数据面"的分工、服务端裁剪为主的协同机制，以及前端掩码/过滤仅为展示层的边界。

• 数据范围类型（本人、本部门、下级部门、全部、自定义）与规则模型
• 范围规则的传递方式（后端注入 SQL vs 前端传参）
• 列表场景的边界（分页一致性、范围变更、审计）

数据范围模型：常见类型枚举——本人（ownerId = 当前用户）、本部门、本部门及下级（部门树）、全部、自定义（deptIds/userIds 集合），后端以"范围规则"挂到角色/用户；规则表达为条件片段（如 dept_id IN (…) 或 owner_id = ?）。工程应用两条路：后端注入——列表查询接口自动注入范围条件（推荐：安全、分页一致，前端零负担）；前端传参——前端按范围参数（scopeType、deptIds）请求（用于灵活性，但参数可篡改，后端必须重新校验范围合法性并以服务端规则为准，前端参数仅作"期望范围"提示）。列表场景要点：分页一致性——范围规则变化（换部门）会导致同一页数据变化，前端在范围切换时重置分页并提示；范围变更（用户被移出部门）通过权限版本刷新；导出/详情同样受范围约束（不能导出权限外的数据）；范围与搜索/筛选叠加（前端筛选在范围内二次过滤）；审计——数据访问按范围记录，异常范围请求（尝试越权传参）记录告警。前端最佳实践：不自己拼范围过滤，服务端返回数据即已过滤，前端只在切换范围上下文时重拉并清分页。

本题考察数据权限在列表的落地。答题核心是范围类型与"后端注入为主"的传递方式、分页/导出/范围切换的一致性与审计边界。

• 审计日志的价值（合规、安全追溯、责任界定）
• 前端可审计的内容（操作行为、权限拒绝）与不可信性
• 审计链路设计（前端埋点 + 后端权威记录、防篡改）

审计日志价值：满足合规（GDPR/审计法）与安全需求——回答"谁在什么时间对什么资源做了什么操作、为什么被拒绝"，支持事件追溯、权限滥用发现与责任界定。前端在审计中的角色：可以记录操作意图与界面行为（点击了导出、看到了什么页面、权限拒绝的 UI 反馈），但前端日志不可作为权威证据（可被篡改/伪造）；权威审计必须由后端在权限裁决点记录——请求到达后记录用户、资源、动作、结果（允许/拒绝）、来源 IP、时间，审计记录"只增不改"（追加式存储、哈希链防篡改、独立存储权限）。前端边界：前端埋点用于"还原操作过程"（结合回放/会话）与"体验优化分析"（拒绝率、权限困惑点），补齐后端没有的上下文（页面路径、操作顺序），但与后端权威日志通过 requestId/操作 id 关联；前端不得自称"审计完成"（审计能力在服务端）；敏感操作（支付、导出）的审计信息（含参数快照）由后端生成，前端仅展示"已记录"提示。设计要点：审计与业务日志分离、PII 最小化（审计不记录密码等）、留存策略（如 180 天）、异常审计模式告警（高频拒绝）。

本题考察审计体系的职责划分。答题核心是"前端记行为过程、后端记权威裁决"的双层审计模型、后端防篡改存储，以及前端审计的体验价值与边界。

• 授权变更审计（谁改了什么权限、何时）与访问日志（谁访问了什么）
• 前端可见的审计信息（变更提示、我的授权记录）
• 前端与后端审计数据的协同（来源权威、关联、导出）

审计内容分两类：授权变更日志——管理员修改用户角色/权限、新建/删除权限点的记录（操作者、目标、变更前后、时间、原因）；访问日志——用户访问页面/资源/执行操作与权限拒绝的记录。权威性归属：授权变更只能由后端记录（前端发起的变更请求，审计由后端在变更事务中写入，含变更前后 diff）；访问日志权威记录也在后端（请求裁决时写入），前端"访问日志"只能算行为轨迹。前端协同形态：管理端审计页面——读取后端审计接口展示（筛选操作者/对象/时间、查看变更 diff 快照、导出报表）；普通用户侧——"我的授权/操作记录"页面（查看自己何时被授予/回收权限，满足知情权）；权限变更提示（管理员操作后实时通知用户权限变化，配合审计记录）。协同要点：前端只读审计数据（不提供修改/删除接口）；审计查询接口本身权限受控（只有审计角色可查）；审计数据与业务数据同源（操作 id 关联）；导出走异步任务（大数据量）；前端埋点的时间戳与后端对齐（时钟偏差），展示以服务端记录为准。

本题考察审计的完整链路。答题核心是"授权变更与访问两类审计都由后端权威记录、前端只读消费"的协同模型，以及审计页面、变更通知与权限受控的要点。

• CSRF 攻击模型与 SameSite Cookie 的防护语义
• CORS 的配置面（允许域、凭据）与误配风险
• 组合策略（SameSite+CSRF Token+Origin 校验）的取舍与前端配合

攻击模型：CSRF 是攻击者诱导浏览器携带用户 Cookie 向目标站发跨站请求（表单/图片 GET 等），防护核心是"让服务端区分合法请求与伪造请求"。SameSite Cookie 属性：Lax（默认，跨站顶级导航 GET 携带）、Strict（跨站全不携带）、None（需 Secure，完全携带）——SameSite=Lax/Strict 已挡掉大部分跨站 CSRF，是最经济的一层。CORS 管"浏览器允许前端读取跨域响应"，配置 Access-Control-Allow-Origin 与 Allow-Credentials，误配（*+credentials、多余域名）会放大风险，但它不防 CSRF（请求本身照发）。Origin 校验：服务端校验请求 Origin/Sec-Fetch-Site 头是否在白名单，防跨站请求（针对非浏览器攻击者无效但浏览器场景有效）。组合取舍：现代策略——SameSite=Lax 为基线（登录 Cookie）、敏感写操作加 CSRF Token（双重提交或服务端挑战）或 Origin 校验、CORS 白名单严格化；前端配合：fetch 带 credentials、自定义头触发预检（CORS 预检同时天然带 Origin 供校验）、CSRF Token 从响应头/页面注入后随请求携带（自定义头形式，同时触发预检与 token 校验）。取舍：纯前端 SPA 用 Cookie 会话时 SameSite 是主力；Token 方案（Authorization 头）本身不受 CSRF 影响（非自动携带），可降低 CSRF 面，但需处理存储与刷新。核心：多层叠加，防御纵深，任何一层不单独负责安全。

本题考察跨域安全策略组合。答题核心是 SameSite 防 CSRF 的主力地位、CORS 只约束读取不防 CSRF、Origin 校验做浏览器侧校验，以及 Token 会话方案的取舍与前端配合。

• JWT 无状态与权限撤销的天然矛盾
• 权限变更后旧 token 仍有效的窗口与处置
• kid 头与密钥轮换（rotation）的实现风险与安全实践

风险一：权限撤销延迟——JWT 是自包含无状态凭证，token 有效期内服务端无法"即时撤销"（已签发的权限声明继续有效），角色被回收/用户被禁用后旧 token 仍可访问；缓解：短有效期（access token 15 分钟级）+ 刷新轮换（refresh rotation，刷新时重新签发含最新权限的 token）、权限版本号（token 内嵌 permVersion，服务端比对不匹配即拒绝）、黑名单（服务端维护 jti 黑名单，牺牲无状态性换取即时撤销）。风险二：kid 轮换——JWT header 的 kid 标识验签密钥，密钥轮换时若旧 kid 仍被接受，泄露的旧密钥可继续伪造 token；若新 kid 未及时同步到所有服务，会造成大面积验签失败。安全实践：密钥定期轮换且"旧密钥仅短期保留用于过渡验签"（双密钥：签名用新、验签新旧都接受，过期删除）；kid 与密钥版本严格对应，轮换走配置中心/发布流程，先灰度服务端再统一切换；禁用弱算法与 alg=none；权限尽量以"最小声明"入 token（只放 userId/角色 id），完整权限实时查询服务端（权限服务），避免 token 权限与库内不一致。

本题考察 JWT 权限的时效性风险。答题核心是"无状态 vs 撤销"矛盾的三类缓解手段（短效+轮换、版本号、黑名单），以及 kid 轮换的双密钥过渡与验签同步风险。

• OAuth 2.1 的安全收紧对前端的影响（PKCE、令牌轮换、状态校验）
• 前端授权码流的完整实现（跳转、回调、token 管理）
• 多环境（dev/staging/prod）与多端（SPA/PWA/微前端）的接入治理

工程价值：OAuth 2.1 把安全最佳实践固化为标准（消除隐式流、强制 PKCE、刷新令牌轮换、状态参数必选），前端接入时天然获得"防 token 泄露于 URL、防授权码劫持、防 CSRF 登录"等能力，避免自研 OAuth 的常见漏洞。实践要点：授权码流——前端跳转授权端点（带 client_id、redirect_uri、code_challenge、state），回调页用 code 交换 token（纯 SPA 用 PKCE 无密钥交换，有后端的走后端换）；token 管理——access token 存内存（不落 localStorage 防 XSS 窃取）、refresh token 由后端持有或 httpOnly cookie，刷新用轮换；登出——调用 IdP 端注销并清理本地会话，多标签页同步登出。多环境治理：按环境配置不同 client 与回调白名单、重定向 URI 精确匹配（防开放重定向）、开发环境 mock IdP（离线可测）；微前端场景——统一由基座管理 OAuth 流程与 token，子应用通过注入的上下文获取凭证（避免每应用独立跳转）；PWA/移动端注意回调协议（自定义 scheme）与 app links 的校验。

本题考察 OAuth 2.1 的前端工程化落地。答题核心是安全收紧带来的防护价值、授权码+PKCE 流程与 token 生命周期管理，以及多环境/微前端/移动端的接入治理。

• Token 的分层与多主题映射（品牌主题、暗黑主题、高对比）
• 主题切换机制（data-theme 属性、CSS 变量覆盖、运行时）
• 多品牌的构建与治理（品牌包、组件与 token 版本锁定）

设计核心是"语义 token 与值分离"：组件只引用语义 token（color.bg.surface），主题是"语义 token → 具体值"的映射集合——品牌 A 与品牌 B 是两套品牌色映射，暗黑模式是同一品牌下暗色值映射，高对比/色盲模式是额外的可访问性映射；由此"换品牌=换映射集"，组件零改动。实现机制：W3C DTCG 格式定义多主题 JSON，构建时生成各主题的 CSS 变量（:root 与 [data-theme="dark"] 等作用域），运行时切换只需改 html 的 data-theme 属性（CSS 变量自动生效），结合 prefers-color-scheme 做系统跟随与手动覆盖；深色模式注意中间色（border、shadow、overlay）也要 token 化，避免"把背景反色"的粗暴实现；图片/图标用 CSS filter 或双资源适配。多品牌治理：品牌作为独立 token 包版本化（品牌 A@1.2），组件库发布时锁定 token 版本；按品牌构建产物（CSS 按品牌预生成或运行时切换）；品牌新增走 token 评审（对比度、语义完整性校验）；品牌专属组件（Logo、字体）与通用组件分离。

本题考察主题系统的工程架构。答题核心是"语义 token 与主题映射分离"的模型、data-theme+CSS 变量运行时切换，以及多品牌版本锁定与构建治理。

• Storybook 的文档形态（stories、ArgsTable、MDX、play 测试）
• 跨项目协作（共享组件库文档站、版本化文档、讨论入口）
• 文档质量（API 文档自动生成、示例可运行、变更同步）

Storybook 文档体系：每个组件配 stories（各状态示例：尺寸/主题/错误态/权限态），自动生成 ArgsTable（props 类型与默认值、可交互调参）、Docs 页（MDX 写使用说明与设计规范）、play 函数（交互测试与快照）——文档即示例、示例即测试。跨项目协作模式：组件库仓库托管 Storybook，发布为共享文档站（Chromatic 托管/自建），各项目开发者在文档站查看最新组件 API 与示例；文档随版本发布（文档站按版本存档，旧版本可查）；组件变更 PR 强制附带 story 更新与视觉回归（Chromatic 对比截图），防止"改组件不更文档"；文档站提供 issue/discussion 入口（用 React 组件还是扩展？——评论与使用统计辅助决策）。工程要点：文档与代码同仓库同源（story 与被测组件同目录）、类型驱动文档（TS 类型自动生成 ArgsTable）、文档覆盖边界（无障碍说明、浏览器兼容、权限/主题行为）、示例代码可复制运行（提供可运行沙箱）；跨项目复用流程：需求→查文档站选组件→不满足走组件库提案→组件库开发+文档+测试→发布→项目升级依赖。

本题考察组件库文档的协作闭环。答题核心是"story 即文档即测试"的 Storybook 模式、跨项目共享文档站与版本化协作，以及文档随发布同步的治理机制。