# 1. 前端权限仅为 UI 控制，安全在后端 A 前端隐藏了按钮，用户就无法执行该操作 B 后端返回全量数据由前端过滤是安全做法 C 前端权限数据是合法的授权凭证 D 前端代码与请求可被篡改，前端权限只是 UI 层体验控制，真正的鉴权必须由后端对每个请求独立执行 ✓ 正确答案
# 2. ABAC（属性-based）的动态权限与上下文决策 A ABAC 只适合静态角色场景 B ABAC 基于主体/资源/环境属性实时决策，适合动态上下文场景，实践中常与 RBAC 组合：角色做粗分组、属性策略做细粒度决策 ✓ 正确答案 C ABAC 的策略数量必然少于 RBAC D RBAC 无法表达任何数据级权限
# 3. Critical Action（如支付转账）的二次确认（re-auth、密码、Passkey） A 前端弹出确认框即可保证安全 B 二次确认凭证可以复用多次 C 二次确认按风险分级（交互确认/密码/MFA 或 Passkey），由后端发起一次性挑战并校验，凭证防重放，结果计入审计 ✓ 正确答案 D Passkey 只是更炫的密码，安全性相同
# 4. CSR 中通过后端校验 + 前端隐藏 UI 的边界（不可信前端） A 前端隐藏 UI 只为体验，后端独立校验（权限码+资源归属+防篡改）才是安全执行点，数据按权限裁剪返回 ✓ 正确答案 B 后端校验存在时前端无需任何权限处理 C 前端过滤全量数据是标准做法 D 隐藏的接口前端无法调用
# 5. Storybook 与 Bit 在设计令牌/组件分发与版本化的工程价值 A Storybook 可以替代 Bit 完成跨仓库分发 B Storybook 侧重开发预览与验证，Bit 侧重组件独立版本化与跨仓库分发，二者可组合并配合设计令牌版本化 ✓ 正确答案 C Bit 组件无法独立测试 D 设计令牌不需要版本管理
# 6. 路由守卫（beforeEnter）与组件内权限检查的工程取舍 A 导航守卫拦截页面级访问（重定向/403），组件内检查管区块与数据级权限，两层配合并共享统一权限源 ✓ 正确答案 B 路由守卫可以覆盖页面内所有元素级权限 C 组件内检查应替代所有路由守卫 D 守卫内可以阻塞地同步请求权限数据
# 7. 菜单权限过滤（后端返回菜单树 + 前端递归渲染） A 后端按权限生成裁剪后的菜单树，前端递归渲染并映射路由，配合守卫兜底、孤儿节点治理与缓存刷新 ✓ 正确答案 B 后端返回全部菜单，由前端逐个过滤 C 菜单树无需与路由表对应 D 菜单数据永久缓存即可
# 8. 权限码设计与按钮级权限（v-permission、自定义 Hook） A 权限码按"模块:资源:动作"命名并前后端共用字典，用指令/组件/Hook 实现按钮级控制，后端接口同步校验 ✓ 正确答案 B 权限码粒度越细越好，每个按钮一码 C 按钮权限只需前端判断，后端无需校验 D 权限码可以用任意字符串，无需管理
# 9. 菜单生成器与权限树不一致时的回退（fallback）策略 A 菜单与路由必然一致，无需兜底 B 深链接访问无需校验权限 C 用路由守卫拦截越权访问、菜单渲染校验可达性、403 触发权限刷新自愈，并保证菜单-路由同源生成 ✓ 正确答案 D 权限数据过期不影响菜单显示
# 10. 基于路由 meta 的声明式权限在 Vue Router/React Router 的工程价值 A 权限判断应该散落在每个页面组件中 B React Router 6+ 的 loader 不能做权限校验 C meta 中的权限逻辑可以承载数据级校验 D 在路由 meta 声明权限要求，由全局守卫/loader 统一校验，实现声明与路由同处、静态可查、入口集中 ✓ 正确答案
# 11. 权限变更的实时通知 A 权限变更只需刷新时生效即可 B 收到通知后无需重校验已打开页面 C 权限变更通知只能靠用户手动刷新 D 按场景选 WebSocket/SSE、轮询或权限版本头感知变更，刷新缓存与界面并重校验已打开页面，服务端校验兜底窗口期 ✓ 正确答案
# 12. 前端权限数据如何持久化并在刷新/重登后恢复，权限变更的同步策略如何设计？ A 权限数据应永远存 localStorage，永不清理 B 按安全等级选持久化载体，刷新时恢复并带 loading 态，登出清理，变更同步用版本号/事件/轮询组合 ✓ 正确答案 C 刷新后权限必然丢失，无法恢复 D 登出不需要清理本地权限缓存
# 13. 微前端（qiankun、Module Federation） A 每个子应用应独立完成登录 B 子应用可以修改基座注入的权限数据 C 基座统一登录并把用户与公共权限注入全局状态，子应用按需读取渲染、私有权限自治，密钥不共享、数据只读、命名空间隔离 ✓ 正确答案 D 子应用间可以互相读取对方权限列表
# 14. JWT Token 的签名、Claims 与前端权限解码的安全性边界 A JWT payload 可被前端解码读取，但无法验签，只能用于展示层；敏感信息不入 token，撤销靠短过期+刷新旋转或权限版本号 ✓ 正确答案 B JWT 的 payload 经过加密，前端无法读取 C 前端解码出的权限可以直接信任 D JWT 天然支持权限即时撤销
# 15. RBAC（基于角色的访问控制）在菜单与路由的工程实践 A 前端应自行实现角色继承推理 B 角色名可以硬编码进前端逻辑 C 后端下发角色与合并后的权限集，前端按权限集渲染菜单/路由/按钮，多角色取并集、默认拒绝，判断以权限码而非角色名 ✓ 正确答案 D 权限集合为空时应放行所有功能
# 16. Feature Flag 与权限系统的本质区别（灰度放量 vs 授权控制）及二者的结合模式（按用户/按灰度） A Feature Flag 就是权限系统，只是叫法不同 B Feature Flag 控制功能灰度放量（按分桶），权限系统控制资源授权（按身份），二者叠加决策：flag 放行后再做权限校验 ✓ 正确答案 C Feature Flag 与安全无关，不能用于功能门控 D 权限系统可以完全替代灰度发布
# 17. 按套餐/license 的前端功能门控（SaaS plan gating）设计与后端校验的分工 A 前端根据套餐数据渲染即可，后端无需校验 B 企业版离线 license 无需签名校验 C 套餐变更无需前端感知 D 后端下发套餐/特性/限额，前端做展示与升级引导，额度与操作硬约束必须后端校验，套餐数据不可信 ✓ 正确答案
# 18. 权限变更后已打开页面的失效处理（路由重校验、数据重取、强制登出）与长会话场景策略 A 权限变更只需下次刷新时生效 B 长会话下权限永远不会过期 C 已展示的数据无需重新验证 D 按严重度分档处理：刷新显隐、路由重校验跳转、安全事件强制登出，配合 403 拦截与长会话定期重校验 ✓ 正确答案
# 19. 路由元信息（meta.roles、meta.permissions） A meta 数组语义应为"全部满足"才放行 B meta.permissions/roles 声明"任一满足"，复杂条件用校验函数兜底，守卫统一决策，并做类型化与继承语义规范 ✓ 正确答案 C 每个路由都应在组件内自行实现权限判断 D meta 可以承载真正的安全校验
# 20. TanStack Router 的 beforeLoad 在路由权限的现代实践 A 权限校验应放在 load 中与数据预取一起做 B beforeLoad 在渲染与 load 前执行，可 throw redirect/notFound 终止导航，校验通过后再由 load 预取数据 ✓ 正确答案 C beforeLoad 无法读取路由 context D preload 预取不会触发 beforeLoad
# 21. React Router 6+ 的 loader 在路由级权限校验的工程价值 A loader 在组件渲染后执行，无法拦截无权限渲染 B loader 中无法访问权限上下文 C loader 在渲染与数据加载前执行，可用 throw redirect/Response 终止无权限访问，由 errorElement 承接，并注意预取副作用与层级校验 ✓ 正确答案 D 401 与 403 应走完全相同的处理
# 22. 权限数据懒加载（按需请求菜单与按钮权限）的工程边界 A 权限数据永远应该全量预取 B 懒加载的权限无需缓存 C 懒加载不会引入权限闪烁问题 D 懒加载按模块拉取权限并缓存，需用默认拒绝、loading 骨架与版本号失效处理异步缺口，建议首屏全量+深层懒加载混合 ✓ 正确答案
# 23. 路由动态生成（基于权限配置）的工程实现与现代应用 A 动态路由无需处理刷新场景 B 动态生成无法配合菜单高亮 C 权限变更后旧动态路由无需清理 D 登录后按权限过滤路由配置并动态注册，菜单与路由同源生成，刷新时等待权限就绪、权限变更时重注册并清理旧路由 ✓ 正确答案
# 24. OPA（Open Policy Agent）Rego 策略在前端权限的边界 A 前端可以直接内嵌 OPA 并信任其本地决策 B OPA 决策 API 无网络延迟问题 C Rego 策略只能写 RBAC，无法表达 ABAC D OPA 是后端集中策略引擎，前端只消费已授权结果做渲染增强，决策输入可篡改故不能作为前端安全边界 ✓ 正确答案
# 25. 菜单权限与按钮权限的拆分在后端的 API 设计工程 A 菜单与按钮权限应合并为一个字段下发 B 数据权限与菜单权限无需区分 C 按钮权限可以表达字段级显隐 D 按需选统一或分层接口，菜单/按钮/数据权限分开建模与消费，字段级权限单独建模，后端按页面与操作两层分别校验 ✓ 正确答案
# 26. ReBAC（基于关系的访问控制，Google Zanzibar 风格） A ReBAC 用对象-关系-主体图建模授权，前端通过后端 check 接口消费判定结果渲染 UI，关系变更靠通知刷新，判定安全在后端 ✓ 正确答案 B ReBAC 就是 RBAC 的另一种叫法 C 前端可以自行读取关系图做安全判定 D Zanzibar 只适合谷歌内部，无开源实现
# 27. 权限拦截在 403/401 的重定向与提示的工程实践 A 401 与 403 都直接跳登录页即可 B 并发 401 应逐个刷新 token C 403 应该当成登录过期处理 D 401 走刷新重试-失败跳登录，403 跳无权限页或局部提示，区分页面级与接口级并防重定向死循环 ✓ 正确答案
# 28. 权限点（Permission Key）在多端复用（Web、App） A 各端可以各自定义权限 key B 同名权限点在不同端可以语义不同 C App 端无需权限控制 D 权限点字典在服务端集中定义，各端共用同一 key 与契约，缓存带版本号、变更推送失效，后端统一按权限点校验 ✓ 正确答案
# 29. ACL（访问控制列表）与数据级权限 A ACL 管理对象级授权（谁能对具体资源做什么），数据级权限管理行/字段范围，前端按"过滤后的列表+对象级结果"分层渲染 ✓ 正确答案 B ACL 只适用于后端存储，前端不感知 C 数据范围规则应由前端自由解释 D 字段级脱敏与权限无关
# 30. 权限与角色（Role）的多对多关系在前端的工程模型 A 后端返回角色列表与合并后的权限集，前端消费结果渲染，并集默认、优先级由后端算好，角色切换时刷新权限与缓存 ✓ 正确答案 B 前端应自行维护完整的关系表 C 多角色权限必须由前端做并集运算 D 角色切换不需要清理旧状态
# 31. OAuth 2.1 在 SSO/IdP 的工程价值 A OAuth 2.1 允许继续使用隐式流 B OAuth 2.1 强制授权码流+PKCE 与刷新令牌轮换，前端经 IdP 静默登录与 SLO 集成，本地不存密钥 ✓ 正确答案 C 刷新令牌可以长期复用不轮换 D SPA 可以直接存 client secret
# 32. 权限模型的多租户隔离与租户上下文的工程取舍 A 前端携带的租户 ID 可以作为安全依据 B 跨租户数据访问前端可自行放行 C 共享表模式无需每请求携带租户上下文 D 租户数据隔离由后端强制（鉴权+查询过滤），前端管理租户上下文与切换、切换后刷新权限与清理缓存 ✓ 正确答案
# 33. Casbin RBAC + ABAC 混合模型在前端权限的应用 A Casbin 的 PERM 模型可同时表达角色与属性条件，决策在后端 Enforce，前端只消费决策结果并按其刷新 UI ✓ 正确答案 B 前端应直接内嵌 Casbin 模型文件做决策 C Casbin 无法表达 ABAC 属性条件 D 决策查询接口的结果可以用于安全判定
# 34. 白盒测试，前端绕过防护的安全风险 A 白盒视角下前端一切可绕过（IDOR、接口枚举、参数篡改、重放），防护靠后端独立鉴权、归属校验、签名防重放与最小数据 ✓ 正确答案 B 前端混淆后攻击者就无法构造请求 C 隐藏接口无法被外部调用 D 修改本地权限标记会影响后端鉴权结果
# 35. 权限可视化（权限矩阵、依赖图）的工程价值 A 权限矩阵可以替代策略引擎做决策 B 依赖图无法发现无引用的权限码 C 权限矩阵审查角色差异与冗余，权限依赖图分析权限码引用与孤儿权限，二者是权限治理与收敛的工具 ✓ 正确答案 D 可视化只对安全有用，与治理无关
# 36. 前端权限组件（路由、按钮、菜单、字段级）的设计与复用 A 按钮权限组件就足够覆盖所有场景 B 路由/菜单/按钮/字段四层各自组件化，共享统一权限源与 usePermission 单一入口，变更驱动自动重渲染并可库化复用 ✓ 正确答案 C 各层应各自直接调用接口获取权限 D 权限组件无法支持异步权限加载
# 37. 组件版本管理与发布（Changesets、SemVer） A 破坏性变更可以打 patch 版本发布 B 下游项目永远自动升级即可 C 发布时无需检查产物内容 D 用 SemVer 严格区分破坏性变更与兼容更新，Changesets 自动化版本计算、CHANGELOG 与发布，配合 CI 与 next/canary 预发布通道 ✓ 正确答案
# 38. 组件库架构（基础组件、业务组件、布局组件）的分类 A 基础/布局/业务三层单向依赖，分层带来 API 稳定与独立发布，用 lint 约束跨层依赖、混合组件走组合拆分 ✓ 正确答案 B 业务组件可以依赖任何层，无需约束 C 所有组件都应属于业务层 D 分层与设计系统落地无关
# 39. 设计系统（Design Tokens、Figma 到代码的同步） A 设计师改完 Figma 即可自动上线，无需审查 B Token 变更不影响无障碍 C 样式文件可以任意硬编码颜色值 D Token 按基础/语义/组件分层并以 DTCG 格式管理，Figma 与代码经插件/CI 双向同步，变更需评审、版本化并支持多主题 ✓ 正确答案
# 40. 按需加载与 Tree Shaking 的组件库设计 A 组件库只要发布压缩代码就能自动摇树 B 样式文件应全部合并为一个 css 导入 C 发布 ESM 产物并声明 sideEffects，提供子路径导入与样式拆分，用打包分析验证单组件引入体积 ✓ 正确答案 D 模块顶层副作用不影响摇树
# 41. 权限模型与数据模型（数据级权限、字段级脱敏）的协同 A 字段脱敏可以完全由前端实现 B 数据权限规则可以作为前端安全依据 C 列表数据应由前端自行过滤 D 操作权限控动作入口，数据权限控行/字段，服务端裁剪返回、前端掩码仅展示，越权访问后端拒绝 ✓ 正确答案
# 42. 权限的数据权限（Data Scope）在列表过滤的工程应用 A 数据范围过滤应由前端自行实现 B 前端传参的范围参数可以直接信任 C 范围规则以后端注入查询为主，前端只在范围上下文切换时重置分页重拉，导出与详情同受范围约束并做审计 ✓ 正确答案 D 分页与范围规则无关
# 43. 权限审计日志在前端用户操作追溯系统的工程价值与边界 A 前端日志即可作为审计证据 B 权威审计由后端在权限裁决点追加式记录（防篡改），前端埋点还原操作过程与体验分析，两者以操作 id 关联 ✓ 正确答案 C 审计日志可以任意修改 D 审计只需记录成功操作
# 44. 前端权限审计如何记录授权变更与访问日志，审计数据与后端的协同怎么做？ A 授权变更与访问日志由后端权威记录（含 diff 快照），前端只读展示审计页面与用户操作记录，审计查询接口受控 ✓ 正确答案 B 授权变更审计可以由前端自行记录 C 前端可以提供审计数据修改接口 D 审计数据无需与业务操作关联
# 45. CSRF/SameSite/CORS/Origin 校验在跨域 API 的策略组合工程取舍 A 配置好 CORS 即可防住 CSRF B SameSite=None 是默认推荐值 C Authorization 头方案也无法避免 CSRF D SameSite Cookie 拦截大部分跨站请求，敏感写操作叠加 CSRF Token 或 Origin 校验，CORS 白名单收紧，多层纵深组合 ✓ 正确答案
# 46. JWT 中存储权限在撤销失效与 kid 轮换的工程风险 A 用短效 token+刷新轮换、权限版本号或 jti 黑名单缓解撤销延迟；kid 轮换用新旧双密钥过渡并同步配置，权限尽量少放 token ✓ 正确答案 B JWT 天然支持权限即时撤销 C kid 轮换没有任何风险 D token 内权限声明永远与库内一致
# 47. OAuth 2.1 在现代前端项目的工程价值 A OAuth 2.1 允许在 URL 中直接携带 token B 重定向 URI 可以配置为任意地址 C 刷新令牌可以不轮换以简化实现 D OAuth 2.1 强制 PKCE、令牌轮换与 state 校验，前端按授权码流接入并管理 token 生命周期，多环境与微前端统一凭证治理 ✓ 正确答案
# 48. 多品牌与暗黑模式的 Token 体系 A 暗黑模式只需把背景色反色即可 B 组件只引用语义 token，品牌/暗黑/高对比是不同映射集，用 data-theme 与 CSS 变量运行时切换，品牌包独立版本化 ✓ 正确答案 C 品牌切换需要重写所有组件 D 暗黑模式无需 token 化中间色
# 49. 跨项目复用与组件库的文档（Storybook）协作 A 组件文档可以在组件发布后再补写 B 文档站只服务组件库团队内部 C 组件库以 Storybook 建共享文档站（story 即示例即测试），变更强制更新文档并做视觉回归，文档随版本存档，跨项目按"查文档-提案-发布-升级"协作 ✓ 正确答案 D 视觉回归与文档无关
