# 1. 渐进式拆分（模块化/微前端）的依赖管理如何避免版本冲突与循环依赖？ A 循环依赖只要运行时不报错就没问题 B React 双实例不会影响功能 C 用统一版本/peerDependencies/shared 单实例防版本冲突，用依赖方向约束、提取公共包与 lint/检测工具防循环依赖 ✓ 正确答案 D 微前端应用间可以随意互相 import 源码
# 2. BFF 在 Token 代理、Refresh Token Rotation 与安全隔离的角色 A BFF 模式下前端需要自行持有 refresh token B BFF 只是简单的请求转发，无安全价值 C BFF 集中持有并轮换 refresh token（httpOnly cookie），代理下游请求，前端只拿短期凭证，降低 XSS 与 token 暴露面 ✓ 正确答案 D 刷新令牌轮换可以由前端直接完成
# 3. 领域驱动设计（DDD）限界上下文在前端拆分的工程价值 A 前端按限界上下文组织模块，上下文内高内聚、上下文间以 API 契约与防腐层集成，支持独立演进与团队自治 ✓ 正确答案 B 限界上下文只适用于后端领域模型 C 所有上下文应共享同一个全局 store D 上下文拆得越多越好
# 4. 微前端拆分粒度（按业务/按团队/按变更频率）的工程取舍 A 拆分粒度越细越好 B 按业务/团队/变更频率三维考量，结合耦合度与发布频率评估，高耦合同步发布的不拆，优先模块化再考虑应用级拆分 ✓ 正确答案 C 微前端拆分没有成本 D 所有系统都适合拆成微前端
# 5. 按业务域、页面、功能拆分的粒度权衡 A 以页面为默认拆分单元，业务域内聚领域、跨域共享下沉公共组件层，按内聚与变更频率权衡避免过度拆分 ✓ 正确答案 B 所有共享代码都应拆成功能级单元 C 业务域粒度越小越好 D 页面级拆分无法配合路由懒加载
# 6. 单体前端 → 模块化 → 组件化 → 微前端的演进路径 A 架构演进应一次性重写到位 B 演进过程中无需监控回归 C 微前端适合所有规模的团队 D 按"单体→模块化→组件化→微前端"增量演进，每阶段有推动力与退出条件，先打好模块边界再考虑微前端 ✓ 正确答案
# 7. Feature Flag 在渐进式拆分与 A/B 测试的工程价值 A Flag 打开后可以永远保留在代码中 B 前后端 flag 可以各自独立定义 C Flag 解耦部署与上线，支撑灰度迁移（渐进式拆分闸门）与 A/B 分桶归因，需类型分离、安全默认值与上线后清理 ✓ 正确答案 D 实验 flag 与发布 flag 无需区分
# 8. 架构决策记录（ADR）与技术债务管理 A 技术债务无法量化，只能凭感觉 B ADR 记录决策背景/内容/后果使决策可追溯，技术债务清单化量化并按节奏偿还，偿还时更新相关 ADR 的后果 ✓ 正确答案 C ADR 应该在项目结束后统一补写 D 新架构决策无需评估既有债务
# 9. 渐进式拆分（Strangler Fig Pattern）在遗留系统的工程价值 A 遗留系统改造应该整体重写 B 新旧系统可以各自定义用户身份 C 以路由/模块为单位增量替换旧实现，新旧并存共用身份与契约，对照验收双轨一致性，替换完成即清理旧代码 ✓ 正确答案 D 迁移期间无需对比新旧行为
# 10. 架构演进与团队规模匹配（LSP、Conway's Law） A 架构与团队组织无关 B 大团队应该使用单体架构 C 康威定律要求模块边界对齐团队边界，稳定依赖原则让依赖指向稳定核心，架构形态按团队规模与发布协调成本匹配 ✓ 正确答案 D 小团队上微前端能降低基建成本
# 11. Islands 架构与 RSC 的边界 A Islands 默认静态 HTML、交互孤岛按需水合，适合内容型站点；RSC 让服务端组件与客户端组件显式分层，适合复杂动态应用 ✓ 正确答案 B Islands 与 RSC 是同一个概念 C RSC 的服务端组件也会打包到客户端 D Islands 架构无法处理任何交互
# 12. Monorepo 与 Polyrepo 在大型前端项目的工程取舍 A Monorepo 一定优于 Polyrepo B Monorepo 不需要包边界约束 C Polyrepo 不存在版本漂移问题 D Monorepo 换统一依赖与原子提交，Polyrepo 换独立发布与强隔离，按团队结构与发布节奏取舍，Monorepo 内可划发布组兼顾 ✓ 正确答案
# 13. 垂直拆分（按业务域）相较水平拆分（按层）的工程边界 A 垂直拆分按业务域内聚（域内含组件/状态/API），域内再分层、跨域共享下沉公共层，域间禁止互相依赖 ✓ 正确答案 B 水平拆分更适合大型项目长期演进 C 垂直拆分会导致变更分散 D 两种拆分方式无法结合
# 14. BFF（Backend for Frontend）层在前端的协作模式与工程实践 A BFF 只是把多个接口拼在一起，无其他职责 B BFF 部分下游失败时应整体报错 C BFF 的响应类型不需要与前端共享 D BFF 由前端团队维护（聚合/裁剪/代理），契约先行共享类型，本地 mock 联调，独立部署并与前端 trace 贯通 ✓ 正确答案
# 15. Clean Architecture 在前端（Entity、Use Case、Interface） A 前端框架属于最内层 B 用例层可以直接依赖 React 组件 C 所有前端项目都应完整套用 Clean Architecture D 领域层（实体/用例）不依赖框架，适配器实现用例端口，收益是可测试与可替换，但应按业务复杂度局部应用避免样板代码 ✓ 正确答案
# 16. Hexagonal Architecture（端口与适配器） A 六边形架构中外部技术可以深入内核 B 端口必须由框架自动生成 C 领域内核通过入站/出站端口与外部交互，适配器实现端口可替换，与 Clean Architecture 等价，按领域复杂度局部应用 ✓ 正确答案 D 六边形架构与测试无关
# 17. DDD（领域驱动设计）在前端的限界上下文（Bounded Context） A 前端所有模块共享同一领域模型 B 按统一语言识别上下文边界，前端按上下文组织目录/状态/类型，跨上下文用防腐层转换或共享内核协作 ✓ 正确答案 C 跨上下文可以直接修改对方状态 D 共享内核越大越好
# 18. 前端代码分割（按业务域、按团队）的工程实践与现代应用 A 代码分割只适用于路由级 B 按路由/组件/库/条件四类维度动态 import 分割，配合 Suspense、预取与 hash 缓存，控制 chunk 数量与体积预算避免过度分割 ✓ 正确答案 C chunk 加载失败无需处理 D 分割越多性能越好
# 19. ESLint Boundaries 插件在模块依赖边界的工程价值 A 依赖边界只能靠代码评审约束 B boundaries 规则无法配置例外 C 用 tag 与 import 规则把架构边界变成可执行 lint，CI 与编辑器实时拦截违规依赖，支撑模块化与 monorepo 边界治理 ✓ 正确答案 D 该插件只检查文件命名
# 20. Nx Tags 在 Monorepo 模块边界的工程实践 A Nx tags 只用于构建缓存，不约束依赖 B 按 type/scope 双维打 tag，用 enforce-module-boundaries 规则声明允许/禁止的依赖方向，lint 与 CI 强制边界，配合影响图检查 ✓ 正确答案 C 边界规则只能全局一条 D 新增项目无需打 tag
# 21. Turbo Generators 在新模块脚手架的工程应用 A Turbo Gen 只能生成配置文件 B 生成器模板应保持长期不变 C 生成的代码无需校验 D 用配置+生成器+模板实现新模块一键脚手架（目录/测试/规范注入），模板随规范维护，生成产物过 lint/type 校验 ✓ 正确答案
# 22. 前端公共库（common、ui、utils）的依赖边界与版本管理 A 公共库之间可以任意互相依赖 B 公共库破坏性变更无需迁移指引 C 业务逻辑写在 ui 库中是可以接受的 D utils/common/ui 分层边界清晰且依赖单向，独立 SemVer 发布、框架用 peerDependencies，用 lint 规则与评审防边界失守 ✓ 正确答案
# 23. BFF 接口聚合、协议转换、为不同端定制 API A BFF 聚合接口应返回所有下游全量数据 B 部分下游失败时应整体返回错误 C 按页面场景编排下游调用（并行/串行+超时降级），统一协议与错误模型，按端定制字段与鉴权，并做聚合监控 ✓ 正确答案 D 所有端应使用完全相同的接口
# 24. GraphQL BFF（Apollo Federation/GraphQL Mesh） A GraphQL 查询天然支持 HTTP 缓存，无性能风险 B REST BFF 必然优于 GraphQL BFF C GraphQL Mesh 要求所有服务先重写为 GraphQL D Apollo Federation 用子图+网关聚合多服务 schema，GraphQL Mesh 接入异构 REST 源，取 GraphQL 的类型安全与按需取数，但需治理缓存、N+1 与查询复杂度 ✓ 正确答案
# 25. tRPC（TypeScript-only）与 oRPC（跨语言） A tRPC 支持任意后端语言 B tRPC 的类型在运行时自动校验 C tRPC 靠 TS 类型推断实现零生成的端到端类型安全（适合全 TS 全栈），oRPC 用 schema 驱动跨语言生成（适合多语言后端） ✓ 正确答案 D oRPC 只支持 TypeScript
# 26. GraphQL BFF 与 tRPC/oRPC 端到端类型化 A GraphQL 靠 schema+codegen 类型化（适合多服务聚合与多端），tRPC 靠类型推断零生成（适合全 TS），可按"前端 tRPC + BFF 内部 GraphQL"分层组合 ✓ 正确答案 B GraphQL 与 tRPC 的类型化机制完全相同 C tRPC 无法与 GraphQL 共存 D codegen 步骤可以完全省略
# 27. API Gateway 与 BFF 的区别 A Gateway 是横向的统一入口（鉴权/限流/路由），BFF 是纵向的按端业务适配（聚合/裁剪），协同部署且不互相越界 ✓ 正确答案 B Gateway 与 BFF 职责完全相同 C BFF 应自己实现限流熔断 D 一个 BFF 可以服务所有端
# 28. GraphQL Federation 在多团队 BFF 协作的应用 A 所有团队共用一个子图 B 每团队独立拥有并发布子图，通过实体键与 schema 评审协作，网关聚合统一 API，子图独立鉴权与灰度升级 ✓ 正确答案 C 子图之间可以互相 import 实现 D 子图变更无需兼容性检查
# 29. 前端路由层（router）与业务层的拆分在大型应用的工程实践 A 业务逻辑应写在路由配置中 B 路由层集中管理导航/守卫/数据加载，业务层负责页面逻辑，业务层不直接依赖路由 API，错误按路由级与页面级分层承接 ✓ 正确答案 C 路由层应该包含所有业务规则 D 页面组件应自行管理所有数据加载
# 30. 状态管理的分层（UI、Domain、Infrastructure） A 所有状态都应该放进全局 store B 弹窗开关属于领域状态 C 服务端数据应全部手写进 Redux D UI 状态放组件、领域状态放全局 store、基础设施状态由请求库管理，就近优先，领域层不依赖 UI 状态 ✓ 正确答案
# 31. Web Components 在跨技术栈（React、Vue、Svelte） A 基于原生标准封装组件可跨框架复用，需处理自定义事件/属性/表单适配、Shadow DOM 样式注入，并关注 SSR 与无障碍边界 ✓ 正确答案 B Web Components 只能用于 React C Shadow DOM 会破坏样式隔离 D Web Components 无法与原生表单集成
# 32. 前端架构从单体到微前端渐进式迁移策略的工程实践与边界 A 微前端迁移应该一步到位全量切换 B 先治理模块边界再路由分流试点、按域逐块迁移，全程可回滚并监控对比，设定停止/合并信号控制成本 ✓ 正确答案 C 迁移时可以顺手重写业务逻辑 D 迁移完成后旧模块可以无限期保留
# 33. BFF 的部署、扩展性与故障隔离 A BFF 无状态水平扩展、独立部署且先于前端发布新契约，下游调用短超时+熔断+降级，自身监控聚合延迟与错误率 ✓ 正确答案 B BFF 可以持有本地会话状态 C BFF 可以无限重试下游请求 D BFF 应与前端完全同步发布，不允许灰度
# 34. Service Worker + Cache API 在 BFF 前置缓存的工程价值 A 按接口配置 cache-first/network-first/SWR 策略与 TTL、版本化缓存 key，支持离线与弱网降级，实时与私有数据谨慎缓存 ✓ 正确答案 B SW 缓存适合缓存所有接口包括实时支付状态 C SW 缓存无需失效机制 D 缓存可以跨用户共享私有数据
# 35. tRPC（端到端类型安全 RPC）在 TypeScript Monorepo 的工程价值 A tRPC 需要单独维护接口文档 B web 包应直接打包引入 api 的实现代码 C tRPC 的类型在运行时自动生效，无需 zod D Monorepo 同仓共享 router 类型，前端调用即类型安全、变更编译即报错，配合 zod 运行时校验与统一 middleware 治理 ✓ 正确答案
