系统架构设计面试题

本题库共收录 120 道面试题（基础 17 / 进阶 38 / 深入 31 / 架构 34）。本文件收录系统架构设计相关面试题，目标题量 150 道。题型覆盖：概念题、场景设计题、系统设计题、工程化题、性能优化题、安全题、软技能题、综合开放题。难度覆盖：基础、进阶、深入、架构。每道题除标准参考答案外，另附口头回答版，便于面试时快速组织语言。

基础题（16 道）

FB-25-CO-B-001：MVC、MVVM、MVP、MVI 四种架构模式有什么区别？分别对应哪些前端框架？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：架构模式、MVC、MVVM、MVP、MVI 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请比较 MVC、MVVM、MVP、MVI 四种架构模式，说明各自的数据流向、职责划分，以及在前端框架或库中的典型对应关系。

参考答案：

这四种模式都是为了把 UI 与业务逻辑解耦，但划分方式不同。

模式	核心角色	数据流向	前端典型对应
MVC	Model、View、Controller	View → Controller → Model → View	早期 Backbone.js
MVVM	Model、View、ViewModel	View ↔ ViewModel ↔ Model	Vue、Angular
MVP	Model、View、Presenter	View → Presenter → Model → Presenter → View	少数移动端/Web 框架
MVI	Model、View、Intent	Intent → Model → View → Intent	MviKotlin、部分 Compose/Elm 思路

MVC：Controller 接收用户输入并操作 Model，Model 变化后 View 直接渲染。View 和 Model 可能直接耦合。
MVVM：引入 ViewModel 作为 View 的抽象，通过双向绑定（响应式系统）自动同步。Vue 的 ref/reactive 对应 ViewModel，模板对应 View。
MVP：Presenter 作为 View 和 Model 的中介，View 被动，所有逻辑在 Presenter。测试性更好，但样板代码多。
MVI：基于单向数据流和不可变 State，用户操作变成 Intent，经过 Reducer 生成新 State，再驱动 View。Redux、Elm 都受其影响。

最佳实践：

现代前端框架大多走 MVVM + 单向数据流的混合路线，例如 Vue/React Hooks 既有响应式绑定，也推荐 state → view → action → state 的循环。
选型时不必拘泥于模式名称，而要看团队能否据此保持清晰的分层和可测试性。

评分维度：

概念准确性（40%）：是否准确说出四种模式的角色和流向
前端对应能力（30%）：能否把模式映射到 Vue、React、Backbone 等具体框架
数据流理解（30%）：能否用箭头或图示说明单向/双向流动的差异

常见错误：

认为 MVVM 就是双向绑定，忽略了 ViewModel 作为 View 抽象的本质。
把 MVI 和 MVVM 混为一谈，忽略 MVI 的 Intent 和不可变 State。
认为 React 是 MVC，实际上 React 更偏向 View + 单向数据流。

延伸追问：

如果候选人答对了，可追问：Vue 的响应式系统如何体现 MVVM？React 的 Hooks 更像哪种模式？
如果候选人答错了，可引导：从“用户点击按钮后数据如何回到界面”这个流程来区分它们。

相关题目：

FB-25-CO-A-003 DDD 中的核心概念如何映射到前端架构
FB-25-CO-P-003 整洁架构和六边形架构如何在前端落地

参考资源：

口头回答版：

MVC、MVVM、MVP、MVI 都是把界面和业务逻辑分开的架构模式。MVC 是 Controller 处理输入、操作 Model，然后 View 显示；MVVM 是 ViewModel 作为 View 的抽象，通过双向绑定自动同步，Vue 和 Angular 就是典型；MVP 是 Presenter 作为中介，View 更被动，测试性好但代码多；MVI 是单向数据流，用户操作变成 Intent，生成新的 State 再驱动 View，Redux 这种思路比较像。现在前端通常是 MVVM 加单向数据流的混合。

FB-25-CO-B-002：什么是 BFF（Backend for Frontend）？它解决了什么问题？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：BFF、前后端协作、API 适配、多端 出现频率：高频 预计回答时长：2-3 分钟

题目描述：请解释 BFF（Backend for Frontend）的概念，说明它出现的背景、解决的问题，以及前端与 BFF 的典型协作方式。

参考答案：

BFF 是“为前端服务的后端层”，位于前端应用与底层微服务/数据源之间，由前端团队或前后端协作维护。

解决的问题：

接口碎片化：一个页面要调用多个后端服务，前端自己拼装逻辑复杂。
多端差异：Web、App、小程序对数据字段、聚合粒度需求不同。
前后端耦合：前端被迫适应后端的数据库模型或领域划分。
性能问题：减少前端多次请求，改为 BFF 聚合后一次返回。

典型协作方式：

text

┌─────────┐     ┌─────────┐     ┌─────────────────┐
│   Web   │────→│  Web    │────→│  订单服务        │
│   App   │────→│  BFF    │────→│  用户服务        │
│ 小程序  │────→│  Layer  │────→│  库存服务        │
└─────────┘     └─────────┘     └─────────────────┘

最佳实践：

BFF 不应包含核心领域逻辑，只负责聚合、裁剪、适配、鉴权透传。
可按端拆分 BFF（Web BFF、App BFF），也可按业务域拆分。
与底层服务通信优先使用内部高性能协议（gRPC/HTTP），对外暴露 REST/GraphQL。

评分维度：

概念准确性（40%）：是否说明 BFF 是前端专属后端层
问题识别（35%）：能否说出多端适配、接口聚合、前后端解耦等至少 3 个价值
协作方式（25%）：能否用简单图示说明前端-BFF-后端服务的关系

常见错误：

把 BFF 等同于 API 网关。网关偏向通用横切能力（限流、鉴权、路由），BFF 更贴近前端业务。
认为 BFF 应该写大量业务逻辑，导致前后端职责再次混淆。
忽略 BFF 带来的运维和延迟成本。

延伸追问：

如果候选人答对了，可追问：BFF 和 API Gateway 有什么区别？GraphQL 是不是一种 BFF？
如果候选人答错了，可引导：假设一个 H5 页面需要同时调订单、用户、优惠券三个接口，你会怎么优化？

相关题目：

FB-25-SD-A-002 设计一个支持多终端接入的 BFF 层
FB-25-CO-B-004 前端应用拆分有哪些常见策略

参考资源：

口头回答版：

BFF 就是 Backend for Frontend，给前端专门搭的一层后端。它处在前端和真正的业务服务之间，帮前端聚合多个接口、裁剪字段、适配不同端的需求。比如 Web 和小程序要的字段不一样，BFF 可以分别处理。它解决的是接口碎、多端差异大、前端和后端数据模型耦合的问题。但要注意 BFF 不要写太多核心业务逻辑，它主要是适配和聚合。

FB-25-EN-B-003：Monorepo 是什么？与 Multirepo 相比有什么优劣？

题型：工程化题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计、11 Monorepo 标签：Monorepo、Multirepo、代码组织、依赖管理 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 Monorepo 的概念，对比 Monorepo 与 Multirepo，说明各自适合什么场景。

参考答案：

Monorepo 是把多个相关项目/包放在同一个代码仓库中管理；Multirepo 则是每个项目一个独立仓库。

维度	Monorepo	Multirepo
代码共享	容易跨包引用和重构	需要发布 npm 包或 git submodule
版本一致性	统一依赖版本，减少冲突	各项目自行决定，容易碎片化
原子提交	一次提交可跨包改动	难以做到
构建/CI	需要专门的工具链（Nx、Turborepo、Rush）	各自独立，相对简单
权限隔离	较弱，需要额外配置 CODEOWNERS	天然按仓库隔离
仓库体积	随项目增多而变大	单个仓库较小

适用场景：

Monorepo：大型产品矩阵、组件库 + 业务应用、需要频繁跨包重构、团队规模中等且协作紧密。
Multirepo：独立产品、跨组织协作、各项目技术栈差异大、需要强权限隔离。

最佳实践：

使用 pnpm workspace + Turborepo/Nx 管理任务依赖和缓存。
通过 changesets 或 rush change 管理版本和发布。
明确包边界，避免循环依赖和隐式依赖。

评分维度：

概念理解（30%）：能否准确区分两种仓库组织方式
优劣对比（40%）：能否从代码共享、版本管理、CI、权限等维度对比
场景判断（30%）：能否根据团队规模和产品关系给出选型建议

常见错误：

认为 Monorepo 就是把所有代码放一个仓库，忽略了工具链和包边界的治理。
忽视 Monorepo 的构建性能问题，认为不需要远程缓存或任务编排。
把 Monorepo 当成银弹，强行合并技术栈差异很大的项目。

延伸追问：

如果候选人答对了，可追问：Monorepo 中如何处理不同包的版本策略？
如果候选人答错了，可引导：你所在团队有 5 个业务应用共用一套组件库，哪种方式更好？

相关题目：

FB-25-EN-A-004 Monorepo 中如何设计包依赖和版本策略
FB-25-EN-P-007 前端架构从单体到微前端再到模块化的演进

参考资源：

口头回答版：

Monorepo 就是把多个项目或包放在同一个仓库里管理，Multirepo 是每个项目一个仓库。Monorepo 的好处是代码共享和跨包重构容易、版本可以统一、一次提交能改多个包；缺点是仓库会变大、构建和权限管理更复杂，需要用 Nx、Turborepo 这类工具。Multirepo 适合独立产品或者跨组织协作。一般来说，业务应用和组件库联系紧密、经常一起改的话，Monorepo 更合适。

FB-25-CO-B-004：前端应用拆分有哪些常见策略？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计、26 微前端标签：应用拆分、微前端、业务域、路由、模块化 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请列举前端应用拆分的常见策略，说明每种策略的适用场景、优缺点。

参考答案：

常见拆分策略：

按路由拆分
- 每个路由对应一个独立子应用或 chunk。
- 适用：大型 SPA，不同页面由不同团队维护。
- 优点：用户按需加载，构建产物小。
- 缺点：需要运行时路由协调。
按业务域（DDD Bounded Context）拆分
- 按业务边界划分模块或应用，例如订单域、商品域、用户域。
- 适用：业务复杂、团队按域组织。
- 优点：职责清晰，减少跨域耦合。
- 缺点：边界划分需要业务理解。
按技术栈/渲染模式拆分
- 例如营销页用 SSR，管理后台用 CSR，部分用微前端容器聚合。
- 适用：不同场景对性能、SEO、交互要求不同。
按团队拆分（微前端）
- 每个团队独立开发、部署一个子应用，通过微前端框架集成。
- 适用：大型组织、多团队并行交付。
- 优点：团队自治、独立部署。
- 缺点：运行时隔绝、公共依赖、路由/状态共享复杂。
按功能模块拆分（库化）
- 把通用能力抽成包（组件库、工具库、SDK）。
- 适用：存在可复用能力。

最佳实践：

拆分前先画业务域图，避免按技术层一刀切。
优先用“库化 + 路由懒加载”，不得已再用微前端。
明确拆分后的通信、共享、部署策略。

评分维度：

策略覆盖（40%）：能否说出至少 4 种拆分策略
场景匹配（30%）：能否说明每种策略适合什么场景
优劣分析（30%）：能否指出关键优缺点

常见错误：

一谈到拆分就只想到微前端，忽略路由、业务域、库化等更轻量的方式。
忽视拆分后的集成成本，认为拆了就自然解耦。
按技术层（components/services/utils）而不是业务域拆分。

延伸追问：

如果候选人答对了，可追问：你们项目如果要用微前端，你会怎么选择拆分粒度？
如果候选人答错了，可引导：一个电商后台有订单、商品、用户三个大模块，你会怎么组织代码？

相关题目：

FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层
FB-25-CO-A-008 微前端有哪些实现方式

参考资源：

口头回答版：

前端应用拆分常见有几种：按路由拆，把不同页面做成异步加载的 chunk；按业务域拆，比如订单、商品、用户各成一块；按技术栈或渲染模式拆，比如营销页用 SSR、后台用 CSR；按团队拆就是微前端，各自独立部署再集成；还有就是把通用能力抽成库。选型要看团队规模和业务复杂度，一般先用库化和路由拆分，实在不行了再上微前端。

FB-25-CO-B-005：技术选型的一般流程和关键维度有哪些？

题型：概念题难度：🟢 基础 岗位层级：高级 面试知识域：25 系统架构设计标签：技术选型、决策矩阵、评估、风险 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请描述一次合理的技术选型流程，并说明评估技术方案时应关注哪些关键维度。

参考答案：

技术选型不是“哪个火用哪个”，而是基于约束的决策过程。

一般流程：

明确问题与目标：要解决什么痛点？目标指标是什么？
收集约束：团队技术栈、业务规模、交付周期、运维能力、合规要求。
列出候选方案：包括继续使用现有方案。
建立评估维度：给每个维度打分或排优先级。
做 PoC/试点：在小范围验证关键假设。
决策并沉淀 ADR：记录决策理由、风险、回滚方案。
渐进落地与复盘：避免一次性全量切换。

关键评估维度：

维度	关注点
功能匹配	是否满足业务核心需求
性能	首屏、运行时、构建性能
生态与维护	社区活跃度、版本节奏、升级成本
学习曲线	团队上手成本、招聘难度
可测试性	是否容易写单元/集成/E2E 测试
可扩展性	未来业务变化时是否容易扩展
安全风险	漏洞历史、供应链安全、合规
运维成本	部署、监控、回滚复杂度
许可证	开源协议是否允许商业使用

最佳实践：

使用加权评分表减少主观偏见。
把“不换”也作为候选方案，避免为换而换。
关键决策必须形成 ADR，方便后续新人理解。

评分维度：

流程完整性（40%）：能否说出从问题定义到复盘的关键步骤
维度覆盖（35%）：能否列出至少 5 个评估维度
决策意识（25%）：是否提到 PoC、ADR、渐进落地

常见错误：

只看流行度或 GitHub stars 选型。
忽视团队学习成本和现有代码迁移成本。
选型后不做记录，导致后来人重复讨论。

延伸追问：

如果候选人答对了，可追问：如果两个方案分数接近，你怎么做最终决定？
如果候选人答错了，可引导：假设团队现在在 Vue 2 和 Vue 3 之间犹豫，你会怎么分析？

相关题目：

FB-25-CO-B-006 什么是 ADR
FB-25-CP-P-004 如何做一次技术选型决策并沉淀 ADR

参考资源：

口头回答版：

技术选型要先明确问题和约束，比如团队会什么、业务多大规模、多久上线。然后列出候选方案，甚至包括继续用老方案。接着从功能匹配、性能、生态、学习曲线、可测试性、安全、运维成本这些维度打分，必要时做 PoC 验证。最后决策并写 ADR 记录下来，再渐进落地。关键是不要只看哪个火，要看适不适合自己团队。

FB-25-CO-B-006：什么是 ADR（Architecture Decision Record）？为什么要写 ADR？

题型：概念题难度：🟢 基础 岗位层级：高级 面试知识域：25 系统架构设计标签：ADR、架构决策、文档化、技术治理 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请解释 ADR（Architecture Decision Record）是什么，说明它的典型结构和价值。

参考答案：

ADR 是架构决策记录，用来记录“为什么做这个技术选择”的轻量文档。它不关心代码细节，而关心决策背景、方案对比和风险。

典型结构（Markdown ADR）：

markdown

# ADR-001：使用 Monorepo 管理前端项目

## 状态
已接受

## 背景
团队有 5 个业务应用和 1 个组件库，跨项目改动需要多次发版。

## 决策
采用 pnpm workspace + Turborepo 组织为 Monorepo。

## 备选方案
- 继续使用 Multirepo + npm 包发布：版本碎片化，重构困难。
- 使用单一仓库但无工具链：构建慢，依赖管理混乱。

## 后果
- 正面：跨包重构容易，统一版本，原子提交。
- 负面：需要投入 CI 改造和权限治理。

价值：

知识留存：避免“前人挖坑后人踩”。
决策透明：新成员能理解为什么不用某个流行方案。
减少重复争论：同一问题不需要每次换人都重新讨论。
便于复盘：状态可改为“已废弃”并说明替代决策。

最佳实践：

一个 ADR 只记录一个决策。
放在 docs/adr/ 或仓库 adr/ 目录，按编号命名。
状态包括：提案中、已接受、已废弃、已取代。

评分维度：

概念准确性（40%）：是否说明 ADR 是记录决策理由的轻量文档
结构理解（30%）：能否说出背景、决策、备选方案、后果等关键部分
价值认知（30%）：能否说出知识留存、减少重复争论等价值

常见错误：

把 ADR 写成技术方案文档或 API 文档。
ADR 只写结论不写背景和备选方案。
认为 ADR 是形式主义，写了没人看。

延伸追问：

如果候选人答对了，可追问：ADR 和技术方案文档、RFC 有什么区别？
如果候选人答错了，可引导：团队决定从 Vue 2 升级到 Vue 3，应该记录哪些内容？

相关题目：

FB-25-CO-B-005 技术选型的一般流程
FB-25-CP-P-004 如何做一次技术选型决策并沉淀 ADR

参考资源：

口头回答版：

ADR 就是架构决策记录，用来写清楚“我们为什么选这个方案”。它一般包括背景、做了什么决策、考虑过哪些备选方案、有什么后果。写 ADR 主要是把决策知识留下来，让后来的人知道为什么这么选，避免重复争论。它的状态可以是提案中、已接受、已废弃这些。

FB-25-CO-B-007：可维护性、可扩展性、可测试性在架构中分别指什么？

题型：概念题难度：🟢 基础 岗位层级：高级 面试知识域：25 系统架构设计标签：可维护性、可扩展性、可测试性、质量属性 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请从架构视角解释可维护性、可扩展性、可测试性的含义，并说明它们之间的相互关系。

参考答案：

三者都是架构的质量属性（Quality Attributes），关注系统长期健康度。

属性	含义	前端体现
可维护性	修改、修复、理解代码的容易程度	模块边界清晰、命名一致、文档健全、依赖简单
可扩展性	新增功能或应对规模增长的能力	插件化、低耦合、水平扩展、配置化
可测试性	验证系统行为的容易程度	单元测试可独立运行、依赖可 mock、接口稳定

相互关系：

高内聚低耦合同时提升三者。
过度追求可扩展性（过度设计）可能损害可维护性。
可测试性是反馈循环：测试好的系统通常也更易维护和扩展。

架构层面的体现：

分层清晰：UI 层、业务逻辑层、数据访问层分离。
依赖方向稳定：上层依赖下层抽象，不依赖具体实现。
配置与代码分离：环境、主题、功能开关外置。
统一约定：目录结构、命名、错误处理、日志规范。

最佳实践：

用架构测试（如 ArchUnit、dependency-cruiser）防止违规依赖。
定期进行技术债盘点，防止可维护性退化。

评分维度：

概念区分（40%）：能否分别说明三者含义
前端映射（30%）：能否结合前端代码/项目举例
关系理解（30%）：能否说明三者的协同与权衡

常见错误：

把可扩展性简单等同于“能加很多功能”，忽略结构层面的解耦。
认为可测试性只是测试覆盖率，忽略架构设计对测试的影响。
把三者孤立看待，不理解它们会相互影响。

延伸追问：

如果候选人答对了，可追问：你做过什么具体设计同时提升这三个属性？
如果候选人答错了，可引导：如果一个类改了 10 处代码才能加一个小功能，说明哪个属性不好？

相关题目：

FB-25-CP-A-005 如何评估一个前端架构的可扩展性
FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层

参考资源：

口头回答版：

可维护性是说改代码、修 bug、理解代码容不容易；可扩展性是说加新功能或者业务量增长时系统能不能撑住；可测试性是说验证系统行为方不方便。它们都靠高内聚低耦合来提升，但也不能过度设计，不然可扩展性上去了，可维护性反而下来。前端里体现为分层清楚、依赖简单、接口稳定、配置外置这些。

FB-25-CO-B-008：什么是事件驱动架构？前端有哪些典型应用场景？

题型：概念题难度：🟢 基础 岗位层级：高级 面试知识域：25 系统架构设计标签：事件驱动、发布订阅、解耦、消息总线 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请解释事件驱动架构的基本概念，说明它在前端系统中的典型应用场景和优缺点。

参考答案：

事件驱动架构（Event-Driven Architecture，EDA）是一种通过事件的产生、传播和消费来组织组件协作的架构风格。

核心角色：

事件源（Producer）：产生事件，例如用户点击、WebSocket 消息。
事件总线/通道（Bus/Broker）：负责路由事件。
消费者（Consumer）：订阅并处理事件。

典型前端场景：

组件间解耦通信：全局事件总线（谨慎使用）、Redux 的 action、Vue 的 emit。
埋点与监控：把用户行为封装成事件，统一上报。
实时协作：WebSocket 收到服务端事件后，分发到各组件。
微前端集成：子应用之间通过自定义事件或共享事件总线通信。
表单联动：字段变化触发事件，驱动其他字段或校验逻辑。

优缺点：

优点：松耦合、扩展性好、异步处理自然。
缺点：事件流难以追踪、调试困难、可能引入时序问题。

最佳实践：

对事件做 Schema 约束和文档化。
使用显式的事件名常量，避免字符串硬编码。
控制事件总线范围，避免全局滥用。

评分维度：

概念准确性（40%）：能否说明事件源、总线、消费者三要素
场景识别（35%）：能否说出至少 3 个前端典型场景
优劣分析（25%）：能否指出解耦和调试难度两个核心权衡

常见错误：

把事件驱动等同于简单的回调函数。
滥用全局事件总线，导致数据流不可追踪。
忽略事件顺序和幂等性问题。

延伸追问：

如果候选人答对了，可追问：事件驱动和观察者模式有什么关系？Redux 是不是事件驱动？
如果候选人答错了，可引导：一个购物车添加商品后，多个页面都要更新，你会怎么设计通信？

相关题目：

FB-25-CO-P-006 CQRS 和事件溯源在前端有哪些应用场景
FB-25-SC-P-005 设计一个插件化的前端应用

参考资源：

口头回答版：

事件驱动架构就是组件之间不直接调用，而是通过事件来通信。有人产生事件，有总线或通道负责转发，有人订阅消费事件。前端里常见的有组件通信、埋点上报、WebSocket 实时消息、微前端子应用之间通信、表单联动。好处是解耦、容易扩展；坏处是事件流难追踪、调试麻烦，所以要做好事件命名和范围控制。

FB-25-CO-B-009：分层架构是什么？前端项目常见的分层方式有哪些？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：分层架构、职责分离、前端分层、可维护性 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释分层架构的基本思想，列举前端项目中常见的分层方式，并说明每一层的职责和依赖方向。

参考答案：分层架构是将系统按职责水平切分为多个层级，每层只与相邻层交互，降低复杂度并提升可维护性。

常见前端分层：

视图层（View / UI）：页面、组件、模板，负责渲染和用户交互。
业务逻辑层（Domain / Use Case）：纯函数或 Hook，封装业务规则和工作流。
数据访问层（Repository / API）：网络请求、缓存、数据映射，隔离后端接口细节。
基础设施层（Infrastructure）：日志、埋点、存储、鉴权 SDK 等通用能力。

依赖方向：视图层 → 业务逻辑层 → 数据访问层 → 基础设施层，下层不依赖上层。

示例目录：

text

src/
├── ui/           # 视图组件
├── application/  # 用例/业务逻辑
├── domain/       # 实体、值对象
├── repository/   # API、缓存
└── infrastructure/ # 日志、存储

最佳实践：

同层内高内聚，层间通过稳定接口交互。
避免业务逻辑直接调用框架 API。
用依赖倒置让业务层不依赖具体的数据源。

评分维度：

概念准确性（40%）：是否说明分层是为了职责分离和降低耦合
分层覆盖（35%）：能否列出视图、业务、数据、基础设施等常见层
依赖方向（25%）：是否强调上层依赖下层、下层不依赖上层

常见错误：

把分层等同于文件夹分类，忽视依赖方向约束。
业务逻辑层直接调用 UI 框架或 DOM API。
层与层之间随意互相引用，形成循环依赖。

延伸追问：

如果候选人答对了，可追问：业务逻辑层和领域层有什么区别？
如果候选人答错了，可引导：如果一个 API 请求改动导致十个组件要改，说明分层哪里出了问题？

相关题目：

FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层
FB-25-CO-B-007 可维护性、可扩展性、可测试性

参考资源：

口头回答版：

分层架构就是把系统按职责分成几层，每层只干自己的事。前端一般分视图层、业务逻辑层、数据访问层和基础设施层。视图层负责页面，业务层负责规则，数据层负责请求和缓存，基础设施层负责日志、埋点这些通用能力。关键是上层可以调下层，下层不能依赖上层，这样改底层实现不会影响上层业务逻辑。

FB-25-CO-B-010：什么是接口契约？前端如何利用契约进行协作与 Mock？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：接口契约、Mock、前后端协作、OpenAPI 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释接口契约的概念，说明它在前后端协作中的作用，以及前端如何基于契约做 Mock 和类型生成。

参考答案：接口契约是前后端就接口的 URL、方法、请求参数、响应结构、错误码达成的明确约定。

作用：

并行开发：前端不必等后端完成，可基于契约开发。
减少沟通成本：字段含义、类型、可选性一目了然。
自动化校验：后端可校验请求，前端可校验响应。
类型驱动：根据契约自动生成 TypeScript 类型和请求函数。

常见契约形式：

形式	说明
OpenAPI / Swagger	标准化文档，可生成代码和 Mock
JSON Schema	数据校验和文档
GraphQL Schema	强类型查询语言
内部协议文档	非标准，需要人工维护

前端 Mock 方式：

MSW、Mock.js 拦截请求并按契约返回数据。
Vite / webpack devServer 配置 proxy + mock 中间件。
使用生成的 Mock Server（如 prism、mockoon）。

最佳实践：

契约由前后端共同评审，避免单方面定义。
契约变更走版本控制，并通知消费方。
将契约文件纳入 CI 校验，防止 break change 静默通过。

评分维度：

概念理解（40%）：是否说明接口契约是前后端的共同约定
协作价值（30%）：能否说出并行开发、类型生成、校验等价值
Mock 实践（30%）：是否提到 MSW、Mock Server 或代理方案

常见错误：

把接口文档等同于契约，忽略版本化和自动化校验。
Mock 数据与实际响应差异大，导致上线后字段对不上。
认为契约只是后端的事，前端不参与定义。

延伸追问：

如果候选人答对了，可追问：后端修改了契约但忘了通知前端，怎么在流程上避免？
如果候选人答错了，可引导：前后端并行开发时，前端如何做到不依赖后端接口也能联调？

相关题目：

FB-25-CO-B-002 什么是 BFF
FB-25-SD-A-002 设计一个支持多终端接入的 BFF 层

参考资源：

口头回答版：

接口契约就是前后端约定好的接口规范，包括地址、参数、返回结构和错误码。有了契约，前端可以在后端没完成时基于契约做 Mock，还能自动生成 TypeScript 类型。常用的有 OpenAPI、JSON Schema、GraphQL Schema。Mock 可以用 MSW 拦截请求，也可以用 Mock Server。关键是契约要前后端一起定、一起改，变更要通知到消费方。

FB-25-CO-B-011：什么是依赖注入（DI）和控制反转（IoC）？前端有哪些应用？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：依赖注入、控制反转、IoC、解耦、可测试性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释依赖注入和控制反转的概念，说明它们如何解决组件或模块间的耦合问题，并给出前端中的应用示例。

参考答案：控制反转（IoC）是把对象创建和依赖管理的控制权从组件内部转移到外部容器。依赖注入（DI）是实现 IoC 的一种方式：由外部把依赖注入到组件中，而不是组件自己 new 出来。

核心思想：

组件依赖抽象接口，不依赖具体实现。
由容器/框架负责组装依赖关系。

前端应用示例：

React Context + Provider：把服务通过 Context 注入到子树。
Angular DI：通过构造函数注入 Service。
Vue provide/inject：祖先提供依赖，后代注入。
测试时 Mock：注入 Mock 的 API 客户端，方便单测。

示例：

typescript

interface ILogger { log(msg: string): void; }

class ConsoleLogger implements ILogger {
  log(msg: string) { console.log(msg); }
}

class UserService {
  constructor(private logger: ILogger) {}
}

// 注入真实实现
const service = new UserService(new ConsoleLogger());

最佳实践：

只在需要跨层替换实现或测试 Mock 时使用 DI，避免过度工程。
保持注入的依赖数量少，防止构造函数膨胀。
优先使用框架原生机制，不必引入重量级 IoC 容器。

评分维度：

概念区分（40%）：能否解释 IoC 是思想，DI 是实现方式
前端映射（35%）：能否举出 React/Vue/Angular 的注入示例
价值理解（25%）：是否提到解耦和可测试性提升

常见错误：

把 DI 等同于使用 props 传参。
为了用 DI 而引入复杂容器，增加维护成本。
忽略接口抽象，直接注入具体实现。

延伸追问：

如果候选人答对了，可追问：React Hooks 的依赖数组算不算 DI？为什么？
如果候选人答错了，可引导：一个组件里直接 import 了 axios，测试时很难 Mock，你会怎么改？

相关题目：

FB-25-CO-B-007 可维护性、可扩展性、可测试性
FB-25-CO-B-009 分层架构是什么

参考资源：

口头回答版：

控制反转是一种设计思想，就是把创建和管理依赖的权力从组件手里拿出去。依赖注入是其中一种实现，外部把依赖传给组件，组件只管用。前端里 React Context、Angular 的构造函数注入、Vue 的 provide/inject 都是这个思路。这样做的好处是组件之间解耦，测试时也能方便地注入 Mock 实现。

FB-25-CO-B-012：什么是防腐层（Anti-Corruption Layer）？前端为什么需要它？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：防腐层、DDD、API 适配、领域模型、解耦 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请解释防腐层的概念，说明在前端系统中为什么要引入防腐层，以及它通常位于哪里。

参考答案：防腐层（ACL）是领域驱动设计中的模式，用于隔离外部系统模型对本领域模型的影响。它把外部接口或数据模型转换成本领域能理解的模型，防止外部变化直接污染核心业务逻辑。

前端为什么需要：

后端字段频繁变化：如果 UI 直接使用后端 DTO，字段改名会导致多处修改。
领域语言不一致：后端使用技术化字段名，前端 UI 使用业务化命名。
多后端来源：一个前端页面可能聚合多个服务，模型形态各异。

通常位于 Repository / API 层 与 业务逻辑层 之间。

转换示例：

typescript

// 后端 DTO
interface BackendOrder {
  order_id: string;
  total_amount: number;
  created_at: string;
}

// 前端领域模型
interface Order {
  id: string;
  total: Money;
  createdAt: Date;
}

function toDomain(dto: BackendOrder): Order {
  return {
    id: dto.order_id,
    total: { amount: dto.total_amount, currency: 'CNY' },
    createdAt: new Date(dto.created_at),
  };
}

最佳实践：

转换逻辑集中，不要散落在 UI 组件里。
对不稳定的接口优先建立防腐层。
不要把所有字段都映射，只映射业务需要的部分。

评分维度：

概念准确性（45%）：是否说明防腐层是隔离外部模型的转换层
前端价值（35%）：能否指出防止后端字段变化污染 UI 逻辑
位置理解（20%）：是否知道位于 API 层与业务层之间

常见错误：

把防腐层当成简单的接口封装，忽略模型转换。
在组件里直接做 dto 字段转换，导致转换逻辑重复。
对所有接口都建防腐层，增加不必要的样板代码。

延伸追问：

如果候选人答对了，可追问：防腐层和 BFF 有什么区别？
如果候选人答错了，可引导：后端把 order_id 改成 id，前端应该改哪些地方最理想？

相关题目：

FB-25-CO-A-003 DDD 中的核心概念如何映射到前端架构
FB-25-CO-B-002 什么是 BFF

参考资源：

口头回答版：

防腐层是领域驱动设计里的一个模式，用来把外部系统的数据模型转成我们自己的领域模型，防止外部变化直接污染业务逻辑。前端里主要隔离后端接口，后端字段名、结构改了，只要改防腐层的转换逻辑，UI 和业务层不用动。它一般放在 API 层和业务层之间。

FB-25-CO-B-013：API 版本管理有哪些常见策略？前端应如何配合？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：API 版本、版本管理、兼容性、前后端协作 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请列举 API 版本管理的常见策略，说明各自的优缺点，以及前端在版本升级中应做哪些配合。

参考答案： API 版本管理策略：

策略	说明	优点	缺点
URL 路径版本	`/v1/users`、`/v2/users`	直观、易缓存	URL 膨胀
请求头版本	`API-Version: v2`	URL 干净	需要文档约定
Query 参数	`/users?version=2`	简单	容易遗漏
Content-Type 协商	`application/vnd.api.v2+json`	REST 规范	学习成本高

前端配合要点：

版本声明透明：在 API 客户端或配置中显式声明使用的版本。
兼容性处理：不破坏旧版本调用，直到所有消费方完成迁移。
字段废弃提示：关注后端返回的 Deprecation 头或文档公告。
灰度切换：通过功能开关控制新版本接口的启用比例。
迁移计划：与后端约定版本生命周期，避免同时维护过多版本。

最佳实践：

优先采用 URL 路径版本或请求头版本，便于路由和调试。
在 BFF 层做多版本适配，减少前端应用直接感知。
版本升级必须写迁移文档和回归清单。

评分维度：

策略覆盖（40%）：能否说出至少 3 种版本管理策略
优缺点分析（30%）：能否对比 URL、Header、Query 等方式
前端配合（30%）：是否提到配置、灰度、兼容性、迁移

常见错误：

认为版本越多越好，导致维护成本爆炸。
前端硬编码版本号，散在多个组件里。
忽略后端废弃通知，导致突然不可用。

延伸追问：

如果候选人答对了，可追问：后端要下线 v1 接口，你如何保证所有前端应用都已迁移？
如果候选人答错了，可引导：URL 版本和 Header 版本各适合什么场景？

相关题目：

FB-25-CO-B-002 什么是 BFF
FB-25-EN-A-004 Monorepo 中如何设计包依赖和版本策略

参考资源：

口头回答版：

API 版本管理常见有 URL 路径版本、请求头版本、Query 参数和 Content-Type 协商。URL 版本最直观，Header 版本 URL 干净。前端要在 API 配置里显式声明版本，注意兼容性，配合后端做灰度切换和迁移。版本不要维护太多，升级时要有迁移文档和回归清单。

FB-25-CO-B-014：集中式状态管理与局部状态管理各适用于什么场景？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：状态管理、Redux、Pinia、Context、局部状态 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请比较集中式状态管理与局部状态管理，说明各自的优缺点和典型适用场景。

参考答案：集中式状态管理把多个组件共享的状态放到全局 Store；局部状态管理则把状态保留在组件内部或通过父子通信传递。

对比：

维度	集中式状态管理	局部状态管理
适用范围	跨组件/跨页面共享的数据	组件内部或父子之间
可维护性	数据流清晰，便于追踪	简单直观，无需额外概念
复杂度	需要 Store、Action、Reducer 等概念	低
调试	时间旅行、日志友好	依赖组件层级
性能	可能引发大面积更新	影响范围小

典型场景：

集中式：用户信息、权限、购物车、主题、全局消息。
局部：表单临时输入、弹窗显隐、子组件内部 UI 状态。

最佳实践：

优先使用局部状态，必要时再提升到全局。
全局状态按业务域拆分 Slice，避免单一 Store 膨胀。
使用选择器减少无关组件的重新渲染。
不要把服务端缓存状态全部放入全局，可用 TanStack Query / SWR 管理。

评分维度：

概念区分（40%）：能否清楚区分集中式和局部状态
场景判断（35%）：能否举例说明适用场景
最佳实践（25%）：是否提到优先局部、按域拆分、选择器

常见错误：

所有状态都放全局，导致 Store 臃肿。
该共享的状态却通过多层 props 传递，形成 prop drilling。
把服务端原始数据直接当全局状态，缺少缓存策略。

延伸追问：

如果候选人答对了，可追问：React Context 属于集中式还是局部状态？为什么？
如果候选人答错了，可引导：一个只在当前弹窗里用的表单数据，应该放 Redux 吗？

相关题目：

FB-25-CO-B-008 什么是事件驱动架构
FB-25-CO-P-006 CQRS 和事件溯源在前端有哪些应用场景

参考资源：

口头回答版：

集中式状态管理是把共享状态放到全局 Store，适合用户、权限、购物车这种跨组件的数据；局部状态是放在组件内部，适合表单输入、弹窗显隐这种只在局部使用的状态。原则是优先用局部，必要时再提升。全局状态要按业务域拆分，避免 Store 太大，并用选择器减少不必要的渲染。

FB-25-EN-B-015：如何分析前端构建产物并制定优化策略？

题型：工程化题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：构建产物、Bundle 分析、代码分割、Tree Shaking、性能 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端构建产物分析的方法、常用工具，以及如何根据分析结果制定优化策略。

参考答案：构建产物分析是性能优化的基础，目的是识别体积大、重复、未使用的模块。

常用工具：

工具	用途
webpack-bundle-analyzer	可视化 webpack 产物体积
rollup-plugin-visualizer	Rollup/Vite 产物分析
source-map-explorer	基于 source map 分析
Lighthouse	性能指标与加载建议
import-cost	编辑器内实时显示引入成本

分析步骤：

生成产物并可视化：查看各 chunk 和依赖占比。
识别大依赖： lodash、moment、echarts 等是否全部引入？
检查重复依赖：同一库多个版本、不同库功能重叠。
定位未使用代码：Tree Shaking 失效、死代码。
评估代码分割点：路由级、组件级懒加载是否合理。

优化策略：

Tree Shaking：使用 ES Module、避免副作用配置错误。
按需加载：import()、路由懒加载、组件懒加载。
替换大库：moment → dayjs，lodash → lodash-es 或按函数引入。
公共代码提取：runtime、vendor 缓存复用。
压缩与 Gzip/Brotli：开启 minify 和预压缩。

最佳实践：

在 CI 中设置产物体积阈值，防止回归。
记录基线，每次发版对比体积变化。
不只看总体积，还要看首屏加载的关键资源大小。

评分维度：

工具掌握（35%）：能否说出 bundle analyzer、source-map-explorer 等工具
分析思路（35%）：是否能识别大依赖、重复依赖、未使用代码
优化策略（30%）：是否提到 Tree Shaking、懒加载、替换库、公共提取

常见错误：

只看打包后总体积，忽略首屏关键资源。
盲目加懒加载，导致请求数过多或交互延迟。
Tree Shaking 失效却不知道是 import 方式或 sideEffects 配置问题。

延伸追问：

如果候选人答对了，可追问：发现 lodash 被打包进了多个 chunk，你会怎么处理？
如果候选人答错了，可引导：Tree Shaking 是什么情况下会失效？

相关题目：

FB-25-PE-A-006 从架构视角看性能优化如何系统化思考
FB-25-CP-A-005 如何评估一个前端架构的可扩展性

参考资源：

口头回答版：

前端构建产物分析主要靠 webpack-bundle-analyzer、rollup-plugin-visualizer 这些工具可视化体积。分析时要找大依赖、重复依赖、没用的代码和代码分割点。优化可以做 Tree Shaking、按需加载、把大库换成小的、提取公共代码、开启压缩。还要在 CI 里设体积阈值，防止回归。

FB-25-CO-B-016：什么是渐进式增强与优雅降级？前端如何实践？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：渐进式增强、优雅降级、兼容性、可访问性、resilient 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请解释渐进式增强和优雅降级的概念，比较两者差异，并说明前端在兼容性设计中如何实践。

参考答案：渐进式增强（Progressive Enhancement）是先保证核心功能可用，再为能力更强的浏览器或设备添加增强体验。优雅降级（Graceful Degradation）则是先为现代浏览器实现完整功能，再对旧浏览器做降级兜底。

对比：

维度	渐进式增强	优雅降级
起点	基础功能	完整功能
思路	由低到高添加能力	由高到低裁剪能力
适用	内容型站点、可访问性要求高	复杂 Web App、旧环境必须可用
优势	核心体验更稳定	开发体验更接近现代标准

前端实践：

特性检测：使用 if ('IntersectionObserver' in window) 而非 UA 嗅探。
Polyfill 按需加载：通过 core-js 或动态 Polyfill 服务补充缺失 API。
CSS 回退：新属性写前面，旧属性做兜底。
服务端渲染兜底：JS 执行失败时仍能看到静态内容。
响应式图片：srcset + picture 根据设备能力加载不同资源。

最佳实践：

优先渐进式增强，保证核心链路不依赖 JS。
明确浏览器支持矩阵，避免无限兼容。
在 CI 中用真机或 Playwright 做兼容性回归。

评分维度：

概念区分（45%）：能否清楚说明两者起点和思路差异
前端实践（35%）：能否举出特性检测、Polyfill、CSS 回退等例子
选型判断（20%）：是否知道何时选渐进增强、何时选优雅降级

常见错误：

把渐进增强和优雅降级混为一谈。
用 UA 嗅探替代特性检测，导致误判。
为了兼容旧浏览器，放弃所有新特性。

延伸追问：

如果候选人答对了，可追问：如何设计一个既支持现代浏览器又能在 IE11 运行的表单？
如果候选人答错了，可引导：先保证基本内容可访问，再叠加交互，这是哪种策略？

相关题目：

FB-25-CO-B-014 集中式状态管理与局部状态管理
FB-25-PE-A-016 首屏加载架构优化

参考资源：

口头回答版：

渐进式增强是先保证基本功能可用，再给能力强的浏览器加增强功能；优雅降级是先做完整功能，再在旧浏览器上裁掉一些。前端实践可以用特性检测、按需加载 Polyfill、CSS 回退、SSR 兜底。一般内容型站点更适合渐进增强，复杂应用可能优雅降级更现实。

进阶题（17 道）

FB-25-SC-A-001：你负责一个大型中后台系统，如何进行模块拆分和分层？

题型：场景设计题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：中后台、模块拆分、分层架构、业务域 出现频率：高频 预计回答时长：8-12 分钟

题目描述：假设你负责一个包含权限、订单、商品、财务、营销等多个业务域的大型中后台系统。请描述你会如何进行模块拆分和分层，并说明每一层的职责。

参考答案：

模块拆分应遵循“先按业务域、再按技术层”的原则。

业务域划分（纵向切分） 参考 DDD 的限界上下文：
- modules/auth：登录、角色、权限
- modules/order：订单列表、详情、操作
- modules/product：商品管理
- modules/finance：财务流水、对账
- modules/marketing：营销活动、优惠券
技术分层（横向切分） 每个业务域内部保持统一分层：

text

src/
├── modules/
│   └── order/
│       ├── api/           # 数据访问层：HTTP/GraphQL 调用
│       ├── domain/        # 领域层：实体、业务规则、DTO
│       ├── services/      # 应用层：用例编排
│       ├── components/    # UI 组件层
│       └── pages/         # 页面层
├── shared/
│   ├── ui/                # 通用组件
│   ├── utils/             # 通用工具
│   └── types/             # 全局类型
└── app/                   # 框架入口、路由、全局配置

依赖规则
- 上层可以调用下层，下层不依赖上层。
- 业务域之间通过 shared 或显式的跨域 API 包通信，禁止直接 import 对方内部模块。
- 用 dependency-cruiser 或 Nx enforce-module-boundaries 做架构守护。
路由与导航
- 每个业务域注册自己的路由配置。
- 菜单/权限元数据与路由配置合并，统一渲染。

最佳实践：

先识别稳定业务域，再逐步拆分，不要一次拆得过细。
公共能力（表格、表单、权限组件）沉淀到 shared/ui。
每个业务域有独立的测试入口，支持独立运行。

评分维度：

拆分思路（35%）：是否按业务域优先而非技术层优先
分层清晰度（30%）：每层职责是否明确，依赖方向是否合理
可落地性（20%）：是否提到工具、路由、测试等工程细节
扩展性意识（15%）：是否考虑未来新增业务域的成本

常见错误：

按 components/pages/services 全局分层，导致所有业务逻辑混在一起。
业务域之间随意互相引用，形成隐式耦合。
忽视中后台的权限、表单、表格等共性抽象。

延伸追问：

如果候选人答对了，可追问：如果两个业务域都需要查询用户信息，你会把用户服务放在哪里？
如果候选人答错了，可引导：假设订单模块里直接 import 了商品模块的页面组件，这有什么问题？

相关题目：

FB-25-CO-B-004 前端应用拆分有哪些常见策略
FB-25-CO-A-003 DDD 中的核心概念如何映射到前端架构

参考资源：

口头回答版：

我会先按业务域纵向切分，比如权限、订单、商品、财务、营销各成一个模块，每个模块内部再按技术层横向分 api、domain、services、components、pages。业务域之间不能直接引用内部模块，只能通过 shared 或显式跨域包通信。依赖方向要固定，上层调下层。公共的表格、表单、权限组件抽到 shared/ui。这样新增业务域只需要新增一个 modules/xxx，扩展性好，也便于独立测试。

FB-25-SD-A-002：设计一个支持多终端接入的 BFF 层

题型：系统设计题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计、19 Node.js / BFF 标签：BFF、多端适配、API 设计、聚合层 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个 BFF 层，同时服务 Web、iOS App、Android App、小程序四个终端。要求支持不同终端的数据裁剪、字段转换、聚合查询，并说明路由、缓存、错误处理策略。

参考答案：

整体架构

text

┌─────────┬─────────┬─────────┬─────────┐
│   Web   │ iOS App │ Android │  小程序  │
└────┬────┴────┬────┴────┬────┴────┬────┘
     │         │         │         │
     └─────────┴────┬────┴─────────┘
                    │
            ┌───────┴───────┐
            │   API Gateway  │  鉴权 / 限流 / 路由
            └───────┬───────┘
                    │
     ┌──────────────┼──────────────┐
     │              │              │
┌────┴────┐    ┌────┴────┐   ┌────┴────┐
│ Web BFF │    │ App BFF │   │ 小程序 BFF│
└────┬────┘    └────┬────┘   └────┬────┘
     │              │              │
     └──────────────┼──────────────┘
                    │
            ┌───────┴───────┐
            │  商品 / 订单 / 用户 / 库存  │
            │     微服务集群              │
            └───────────────┘

按终端拆分 BFF 的优劣
- 优势：每个 BFF 只为一种终端优化，字段裁剪、协议适配最贴近需求。
- 劣势：代码重复。折中方案是底层共享 domain service，BFF 只做 adapter。
核心能力
- 聚合：一个 BFF 接口内部并发调用多个微服务，组合结果。
- 裁剪：根据终端需要的字段过滤响应。
- 转换：把后端领域模型转成前端视图模型（ViewModel）。
- 协议适配：小程序可能只支持 HTTPS，App 可用 gRPC。
缓存策略
- 服务端缓存：Redis 缓存聚合结果，按终端 + 业务键隔离。
- 客户端缓存：Web 用 CDN/Service Worker，App 用本地缓存策略。
- 短缓存 TTL 用于价格、库存，长缓存用于商品详情。
错误处理
- 部分失败：主服务失败返回整体降级，非关键服务失败可返回空值。
- 统一错误码：BFF 把后端异构错误码映射为前端统一错误码。
- 超时熔断：对下游服务设置超时和熔断，避免级联失败。
安全
- 敏感接口在 BFF 层做鉴权透传和脱敏。
- 不暴露内部服务域名和接口到公网。

最佳实践：

BFF 层保持无状态，便于水平扩展。
使用 GraphQL 时，可由一个 BFF 服务同时服务多端，减少重复代码。
接口版本通过 URL（/v1/）或 Header 管理。

评分维度：

架构完整性（30%）：是否画出或说明网关、BFF、微服务三层
多端适配（25%）：是否提到字段裁剪、协议适配、数据聚合
缓存与性能（20%）：是否设计合理的缓存分层
稳定性（15%）：是否提到熔断、降级、超时、错误映射
安全（10%）：是否提到鉴权透传和脱敏

常见错误：

BFF 层写太多业务逻辑，变成“肥 BFF”。
所有终端共用一个 BFF，导致字段臃肿和频繁 break change。
忽略部分失败场景，一个下游报错就整体 500。

延伸追问：

如果候选人答对了，可追问：如果 Web 和小程序 90% 接口一样，你会合并 BFF 还是保持独立？
如果候选人答错了，可引导：多端需求不同，BFF 应该在哪个层次做裁剪？

相关题目：

FB-25-CO-B-002 什么是 BFF
FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层

参考资源：

口头回答版：

我会在 API Gateway 后面按终端或按业务域拆分 BFF，比如 Web BFF、App BFF、小程序 BFF。Gateway 负责鉴权、限流、路由，BFF 负责聚合多个微服务、按终端裁剪字段、做协议适配。缓存可以分服务端 Redis 和客户端缓存，错误处理要做部分失败降级、统一错误码、超时熔断。BFF 不要写太多业务逻辑，保持无状态便于扩展。

FB-25-CO-A-003：DDD（领域驱动设计）中的核心概念如何映射到前端架构？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：DDD、限界上下文、领域模型、前端分层 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 DDD（领域驱动设计）中的限界上下文、聚合根、实体、值对象等核心概念，并解释它们如何映射到前端代码组织。

参考答案：

DDD 核心概念及前端映射：

DDD 概念	含义	前端映射
限界上下文（Bounded Context）	业务边界内的统一语言	前端业务模块/微前端子应用
聚合根（Aggregate Root）	一组相关对象的访问入口	页面级状态容器或领域 store
实体（Entity）	有唯一标识、状态可变	带 ID 的数据模型，如 `Order`、`User`
值对象（Value Object）	无唯一标识、不可变	地址、金额、颜色等不可变对象
领域服务（Domain Service）	跨实体的业务逻辑	纯函数业务逻辑，如 `calculateTotal`
应用服务（Application Service）	用例编排	React Hooks / Vue Composable
仓库（Repository）	数据持久化抽象	API 层 / TanStack Query / SWR 封装

前端落地示例：

typescript

// modules/order/domain/order.ts
export interface Order {
  id: string;
  items: OrderItem[];
  status: OrderStatus;
}

export function calculateTotal(order: Order): Money {
  return order.items.reduce((sum, item) => addMoney(sum, item.price), zeroMoney());
}

// modules/order/services/usePlaceOrder.ts
export function usePlaceOrder() {
  const repository = useOrderRepository();
  return useMutation({
    mutationFn: (draft: OrderDraft) => repository.create(draft),
  });
}

关键原则：

业务语言统一：前端代码里的命名和后端领域术语对齐。
防腐层（Anti-Corruption Layer）：API 层把后端 DTO 转成前端领域模型，避免后端字段变化污染业务逻辑。
限界上下文内高内聚，上下文之间通过显式接口交互。

最佳实践：

不要在前端照搬 DDD 所有概念，选择对代码组织有帮助的部分。
优先在复杂业务系统（如电商、金融）中落地。
用类型系统强化值对象不可变性。

评分维度：

概念准确性（40%）：能否准确解释 DDD 核心概念
前端映射能力（35%）：能否把概念对应到前端模块、store、Hook、API 层
落地意识（25%）：是否提到防腐层、统一语言、不可变值对象

常见错误：

把 DDD 当成后端专属，认为前端不需要。
在前端创建大量“领域对象”类，增加不必要的样板代码。
忽视防腐层，直接在后端 DTO 上写业务逻辑。

延伸追问：

如果候选人答对了，可追问：前端是否需要聚合根？在 Redux 里它对应什么？
如果候选人答错了，可引导：前端代码里经常有后端字段命名和 UI 命名不一致，DDD 怎么解决这个问题？

相关题目：

FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层
FB-25-SD-P-001 设计一个低代码平台前端架构

参考资源：

口头回答版：

DDD 里有限界上下文、聚合根、实体、值对象、领域服务这些概念。限界上下文对应前端的一个业务模块或微前端子应用；聚合根对应该模块的入口状态；实体是有 ID 可变状态的数据模型；值对象是不可变的，比如地址、金额；领域服务是纯函数业务逻辑；仓库就是 API 层。前端落地时要建一个防腐层，把后端 DTO 转成前端领域模型，避免后端字段变了业务逻辑全挂。命名上要和业务统一语言。

FB-25-EN-A-004：Monorepo 中如何设计包依赖关系、版本策略和发布流程？

题型：工程化题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计、11 Monorepo 标签：Monorepo、依赖管理、版本策略、Changesets、发布 出现频率：中频 预计回答时长：5-8 分钟

题目描述：在一个 Monorepo 中管理多个包时，如何设计包之间的依赖关系？版本策略有哪些选择？发布流程如何自动化？

参考答案：

包依赖关系设计

text

apps/
├── web/              依赖 shared/ui、shared/utils
└── admin/
packages/
├── shared/ui         依赖 shared/utils、shared/types
├── shared/utils      依赖 shared/types
└── shared/types      无依赖

依赖方向：apps → packages，packages 之间形成 DAG（有向无环图）。
禁止循环依赖：用 dependency-cruiser 或 Nx graph 检测。
按稳定性分层：types > utils > ui > apps，底层包尽量稳定。

版本策略

策略	说明	适用
统一版本	所有包共用一个版本号	包之间耦合紧密，如 design system
独立版本	每个包独立 Semver	包之间相对独立
固定依赖	内部包用精确版本	强一致性要求
浮动依赖	内部包用 workspace:*	开发时自动同步

推荐：内部包使用 workspace:* 或 workspace:^，发布时由工具替换为实际版本。

发布流程

text

PR 合并 → changeset 收集 → Version Packages PR → 发布 → Git Tag → 更新 changelog

开发者提交 PR 时附带 .changeset/*.md 说明变更。
CI 定期生成 “Version Packages” PR，自动 bump 版本、更新 changelog。
人工合并后触发 publish。

工具链
- pnpm workspace：依赖安装和 workspace 协议。
- Changesets：版本和 changelog 管理。
- Turborepo/Nx：构建任务编排和缓存。
- GitHub Actions：CI 自动化。

最佳实践：

公共 API 变更必须经过 review，避免 break change 扩散。
每个包声明 exports 字段，控制对外暴露的模块。
对内部包做 semver 约束，小改 patch、新功能 minor、break change major。

评分维度：

依赖设计（30%）：是否提到 DAG、稳定性分层、循环依赖检测
版本策略（30%）：能否比较统一/独立版本、workspace 协议
发布流程（25%）：是否说明 changeset、Version PR、publish 流程
工具意识（15%）：是否提到 pnpm、Changesets、Turborepo 等工具

常见错误：

内部包手动管理版本号，导致版本不一致。
允许循环依赖，构建顺序无法确定。
发布时缺少 changelog，使用者不知道 break change。

延伸追问：

如果候选人答对了，可追问：如果 shared/ui 和 shared/utils 互相依赖了，你会怎么处理？
如果候选人答错了，可引导：Monorepo 里 A 包改了，B 包依赖 A，怎么保证 B 能用到最新版本？

相关题目：

FB-25-EN-B-003 Monorepo 是什么
FB-25-EN-P-007 前端架构从单体到微前端再到模块化的演进

参考资源：

口头回答版：

Monorepo 里包的依赖要形成有向无环图，底层放 types、utils 这些稳定包，上层是 ui、应用，严禁循环依赖。版本策略可以统一版本，也可以独立 Semver，内部包推荐用 workspace:* 协议自动同步。发布流程用 Changesets：PR 里带 changeset，CI 自动生成 Version Packages PR 来 bump 版本和写 changelog，合并后再 publish。工具上就是 pnpm workspace + Changesets + Turborepo。

FB-25-CP-A-005：如何评估一个前端架构的可扩展性？

题型：综合开放题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：可扩展性、架构评估、质量属性、度量 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明评估前端架构可扩展性的方法和指标，并举例说明如何在设计阶段预留扩展点。

参考答案：

可扩展性指系统在面对新需求、新团队、新流量时，能以合理成本扩展的能力。

评估维度：

维度	评估问题	指标/方法
功能扩展	新增一个业务模块需要改多少文件？	模块新增成本、依赖变更范围
团队扩展	新成员能否快速独立开发一个模块？	新人上手时间、文档完整度
流量扩展	构建和运行时能否随规模增长？	构建时间、包体积、运行时性能
技术扩展	能否平滑替换某一层技术栈？	依赖倒置程度、接口稳定性
多端扩展	新增一个端需要多少重复工作？	复用率、BFF 适配成本

设计阶段预留扩展点：

插件化设计：定义扩展点接口，如表单渲染器支持自定义字段类型。

typescript

interface FieldRendererRegistry {
  register(type: string, renderer: FieldRenderer): void;
  get(type: string): FieldRenderer;
}

配置化：把会变动的规则外置，如菜单、权限、主题。
依赖倒置：业务逻辑依赖抽象接口，而不是具体框架 API。
分层隔离：UI 层、业务层、数据层分离，替换某层不影响其他层。
事件/消息总线：新增消费者不需要改动生产者。

评估方法：

场景演练：假设 6 个月后新增一个业务域，模拟需要改多少代码。
架构评审：检查依赖图，识别“上帝模块”。
指标度量：构建时间、包体积、循环依赖数量、测试覆盖率。

最佳实践：

可扩展性不是无限扩展，要在“足够扩展”和“不过度设计”间平衡。
用架构守护工具防止扩展性退化。

评分维度：

维度覆盖（35%）：能否从功能、团队、流量、技术、多端等角度评估
设计方法（35%）：是否提到插件化、配置化、依赖倒置、分层等具体手段
度量意识（30%）：是否提出可量化的指标或评审方法

常见错误：

把可扩展性等同于“能写很多 if-else 兼容未来”。
忽视团队扩展，只关注代码结构。
过度设计，为不存在的需求引入复杂抽象。

延伸追问：

如果候选人答对了，可追问：你实际做过哪些预留扩展点的设计？效果如何？
如果候选人答错了，可引导：如果一个新需求进来要改 20 个文件，说明什么问题？

相关题目：

FB-25-CO-B-007 可维护性、可扩展性、可测试性
FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层

参考资源：

口头回答版：

评估可扩展性我会看几个维度：功能上新增模块要改多少文件、团队上新人能不能快速接手、流量和包体积能不能撑住、技术上能不能换一层实现、多端上复用率怎么样。设计时可以预留插件化接口、把规则配置化、用依赖倒置让业务依赖抽象、分层隔离、用事件总线解耦。评估时可以做场景演练，比如假设半年后加一个业务域要改多少代码，再用工具看依赖图有没有上帝模块。

FB-25-PE-A-006：从架构视角看，性能优化应该如何系统化思考？

题型：性能优化题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计、27 性能工程标签：性能架构、系统化优化、性能预算、架构视角 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请从架构视角出发，说明前端性能优化应该如何系统化思考，而不是只做单点优化。

参考答案：

架构视角的性能优化需要从“目标定义 → 度量 → 瓶颈识别 → 分层优化 → 持续监控”闭环思考。

定义性能目标（Performance Budget）
- 首屏时间 < 1.5s，LCP < 2.5s，TTI < 3.5s，JS 体积 < 200KB 等。
- 不同页面/端可设定不同预算。
建立度量体系
- 实验室数据：Lighthouse、WebPageTest。
- 真实用户数据：RUM（Core Web Vitals）、性能埋点。
- 构建数据：包体积、chunk 数量、依赖重复率。
分层优化

text

架构层：路由拆分、微前端按需加载、BFF 聚合减少请求
资源层：代码分割、图片优化、CDN、缓存策略
渲染层：SSR/SSG、懒加载、虚拟列表、减少重排重绘
运行时：减少主线程阻塞、Web Worker、内存管理

避免单点优化陷阱
- 不要只优化首屏而忽略交互响应。
- 不要只压缩 JS 而忽略图片/字体资源。
- 不要只优化 Web 而忽略小程序/APP 的离线包、预加载。
架构层面的关键决策
- 渲染模式：CSR/SSR/SSG/ISR 的选择。
- 代码分割策略：按路由、按组件、按用户角色。
- 数据获取策略：BFF 聚合、边缘缓存、增量同步。
持续监控与回归防护
- CI 中集成 Lighthouse CI 或包体积检测。
- 建立性能基线，超标自动告警。

最佳实践：

性能优化要和业务指标挂钩（跳出率、转化率）。
用真实用户数据指导优先级，而非只凭实验室数据。
架构师要在设计阶段就确定渲染模式和资源策略，而不是上线后补补丁。

评分维度：

系统化思维（35%）：是否从目标、度量、优化、监控闭环思考
分层能力（30%）：能否区分架构层、资源层、渲染层、运行时
度量意识（20%）：是否提到 Performance Budget、RUM、Lighthouse CI
业务关联（15%）：是否把性能与业务指标关联

常见错误：

只关注代码层面优化，忽略架构层决策。
没有性能目标，优化无止境。
只测实验室数据，忽略真实用户环境差异。

延伸追问：

如果候选人答对了，可追问：如果老板要求首屏 1 秒内，你会从哪一层先开刀？
如果候选人答错了，可引导：性能优化除了压缩代码，还有哪些更大的杠杆？

相关题目：

FB-25-CO-B-008 什么是事件驱动架构
FB-25-SD-A-002 设计一个支持多终端接入的 BFF 层

参考资源：

口头回答版：

性能优化不能只看单点，要从目标、度量、瓶颈识别、分层优化、持续监控这个闭环来做。先定性能预算，比如首屏 1.5 秒、JS 体积 200K；然后用 RUM 和 Lighthouse 度量；再分层看：架构层做路由拆分和 BFF 聚合、资源层做代码分割和 CDN、渲染层做 SSR 或虚拟列表、运行时减少主线程阻塞。最后 CI 里做包体积检测和性能回归告警。关键是要用真实数据指导优先级。

FB-25-SE-A-007：从架构视角看，前端安全应该如何设计？

题型：安全题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计、31 安全架构标签：安全架构、XSS、CSP、供应链安全、零信任 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请从架构视角说明前端安全设计的关键层面，包括运行时安全、构建时安全和组织级安全治理。

参考答案：

前端安全不仅是修复漏洞，而是贯穿架构各层的防护体系。

运行时安全
- XSS 防护：输入校验、输出转义、使用框架自动转义（React/Vue 默认转义文本）、避免 dangerouslySetInnerHTML/v-html 直接渲染不可信内容。
- CSP：配置 Content-Security-Policy，限制脚本、样式、图片来源。
- iframe 安全：使用 sandbox、referrerpolicy、禁止嵌入不可信来源。
- 敏感数据：不在前端长期存储密钥、token 设置 HttpOnly/Secure/SameSite。
构建时安全
- 依赖安全：用 npm audit、pnpm audit、Snyk 检测漏洞。
- 供应链保护：锁定 lockfile、使用私有 registry、校验包签名。
- 代码注入：避免构建脚本执行远程脚本，审查 CI/CD 权限。
架构层面安全
- 零信任：前端默认不信任服务端返回的数据，做 Schema 校验。
- 接口权限：BFF 层做鉴权透传和最小权限校验。
- 错误信息：不暴露内部堆栈、SQL、路径等敏感信息。
- 安全 Headers：HSTS、X-Frame-Options、X-Content-Type-Options。
组织级治理
- 安全编码规范 + Code Review 清单。
- 定期依赖审计和漏洞响应流程。
- 安全培训与红蓝演练。

安全分层图：

text

┌─────────────────────────────────────┐
│  组织治理：规范 / 审计 / 培训 / 响应    │
├─────────────────────────────────────┤
│  构建安全：依赖扫描 / 供应链保护        │
├─────────────────────────────────────┤
│  架构安全：零信任 / 鉴权 / 安全 Headers │
├─────────────────────────────────────┤
│  运行时安全：CSP / XSS / CSRF / 存储安全 │
└─────────────────────────────────────┘

最佳实践：

安全左移：在代码提交和 CI 阶段拦截漏洞。
默认安全：框架默认转义、Cookie 默认 Secure/HttpOnly。
安全是每一个人的责任，不只是安全团队。

评分维度：

分层完整性（35%）：能否覆盖运行时、构建时、架构层、组织治理
具体措施（35%）：是否提到 CSP、XSS、依赖审计、零信任等具体手段
架构意识（20%）：是否从设计阶段考虑安全，而非仅事后修补
治理意识（10%）：是否提到规范、审计、培训等组织措施

常见错误：

只关注 XSS，忽略供应链和构建时安全。
认为框架自动转义就足够，忽略富文本、URL、JSONP 等场景。
安全策略一刀切，影响业务功能而不做分级。

延伸追问：

如果候选人答对了，可追问：微前端场景下，子应用之间的安全隔离怎么做？
如果候选人答错了，可引导：前端代码里哪些地方可能引入供应链风险？

相关题目：

FB-25-SD-A-002 设计一个支持多终端接入的 BFF 层
FB-25-SD-R-001 设计一个组织级前端架构治理体系

参考资源：

口头回答版：

前端安全要分层看。运行时要做 XSS 防护、配 CSP、敏感 token 不要放 localStorage；构建时要做依赖审计、供应链保护、lockfile 锁定；架构层要零信任，服务端返回的数据要校验，BFF 做鉴权透传，配好安全 Headers；组织级要有安全规范、Code Review 清单、定期审计和响应流程。安全要左移到开发和 CI 阶段，不能等上线后再补。

FB-25-CO-A-008：微前端有哪些实现方式？各自的优缺点是什么？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计、26 微前端标签：微前端、qiankun、Module Federation、iframe、Web Components 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请列举微前端的几种实现方式，对比它们的优缺点和适用场景。

参考答案：

微前端常见实现方式：

实现方式	原理	优点	缺点	适用场景
iframe	浏览器原生隔离	隔离最强、实现简单	体验差、路由同步难、共享能力弱	旧系统迁移、强隔离要求
qiankun/single-spa	基于 JS 沙箱和路由分发	体验接近 SPA、生态成熟	JS 沙箱有边界、样式隔离需额外处理	中大型 SPA 聚合
Module Federation	运行时共享模块	共享依赖最自然、体验好	技术栈要求一致、构建复杂	同技术栈多团队协作
Web Components	原生组件封装	标准方案、框架无关	生态成熟度、跨框架通信复杂	组件级复用、设计系统
路由分发 + Nginx	按路径代理到不同应用	简单、无侵入	只是聚合，不是真正微前端	简单门户

选择建议：

强隔离优先：iframe。
体验优先且技术栈一致：Module Federation。
多技术栈、独立部署：qiankun/single-spa。
组件级跨框架复用：Web Components。

关键挑战：

样式隔离：Shadow DOM、CSS Modules、命名空间、构建时样式前缀。
JS 隔离：Proxy 沙箱、快照沙箱、iframe 原生隔离。
公共依赖共享：externals、Module Federation shared、运行时模块映射。
路由与状态：基座路由统一分发，子应用不直接操作全局状态。

最佳实践：

微前端是组织问题的技术解决方案，不要为了技术而拆分。
明确通信协议，避免子应用强耦合。
统一基座能力：登录、权限、埋点、错误上报。

评分维度：

方案覆盖（35%）：能否说出至少 4 种实现方式
对比分析（35%）：能否从隔离性、体验、共享能力、复杂度维度对比
场景判断（20%）：能否根据场景给出选型建议
挑战认知（10%）：是否提到样式隔离、JS 隔离、公共依赖等挑战

常见错误：

一说到微前端就只会 qiankun，不了解其他方案。
忽视微前端带来的复杂度，认为拆分就能解决所有问题。
子应用之间随意共享状态，导致耦合。

延伸追问：

如果候选人答对了，可追问：Module Federation 和 qiankun 在共享依赖上有什么区别？
如果候选人答错了，可引导：iframe 隔离性最强，为什么大部分微前端方案不用它？

相关题目：

FB-25-CO-B-004 前端应用拆分有哪些常见策略
FB-25-SC-R-003 设计一个大型电商活动搭建平台前端架构

参考资源：

口头回答版：

微前端实现方式主要有 iframe、qiankun/single-spa、Module Federation、Web Components、路由分发这几种。iframe 隔离最强但体验差；qiankun 是 JS 沙箱加路由分发，比较成熟但样式隔离要注意；Module Federation 适合同技术栈团队，共享依赖最自然；Web Components 是标准方案但生态没那么成熟。选型看需求：强隔离用 iframe，体验好技术栈一致用 Module Federation，多技术栈独立部署用 qiankun。要注意样式隔离、JS 隔离、公共依赖共享和通信协议。

FB-25-SC-A-009：设计一个前端配置中心（Feature Flag）系统

题型：场景设计题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：配置中心、Feature Flag、灰度发布、开关系统、配置管理 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请设计一个前端配置中心，支持功能开关、灰度发布、配置下发和回滚。说明配置结构设计、下发链路、缓存与一致性策略。

参考答案：前端配置中心的目标是让功能上线与代码发布解耦，支持按用户、环境、比例灰度。

整体架构：

text

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  配置后台    │────→│  配置服务    │────→│  客户端 SDK  │
│  （管理 UI） │     │  （API/缓存） │     │  （Web/App） │
└─────────────┘     └─────────────┘     └─────────────┘

配置结构设计：

json

{
  "featureNewCheckout": {
    "enabled": true,
    "rules": [
      { "type": "userId", "operator": "in", "value": ["u1", "u2"] },
      { "type": "percentage", "value": 10 },
      { "type": "fallback", "value": false }
    ]
  }
}

核心能力：

功能开关：布尔值控制功能显隐。
灰度规则：按用户 ID、地区、设备、百分比、时间窗口等维度。
实时下发：长连接推送或轮询拉取配置。
本地缓存：localStorage / 内存缓存，保证离线可用。
回滚机制：后台一键关闭开关，客户端立即生效或下次拉取生效。

一致性策略：

配置版本号 + ETag，避免重复全量下发。
关键开关与业务请求合并下发，减少请求数。
客户端 SDK 提供同步和异步两种读取方式，并处理未就绪时的默认值。

最佳实践：

开关必须有默认值，服务端不可用时业务不中断。
定期清理废弃开关，防止代码里充满死逻辑。
变更记录留痕，便于审计和回滚。

评分维度：

架构完整性（30%）：是否覆盖管理后台、配置服务、客户端 SDK
灰度规则（25%）：能否设计多维度规则并处理优先级
一致性与缓存（25%）：是否考虑版本、缓存、默认值
可运维性（20%）：是否提到回滚、审计、清理

常见错误：

开关没有默认值，服务异常时页面报错。
所有配置都实时拉取，导致请求数爆炸。
灰度规则优先级混乱，用户同时命中多条规则。

延伸追问：

如果候选人答对了，可追问：配置下发失败时，客户端应该展示新功能还是旧功能？
如果候选人答错了，可引导：灰度发布和 A/B 测试有什么异同？

相关题目：

FB-25-SD-A-002 设计一个支持多终端接入的 BFF 层
FB-25-SC-P-005 设计一个插件化的前端应用

参考资源：

口头回答版：

前端配置中心就是把功能开关和灰度规则统一管理起来。管理后台配置规则，配置服务下发，客户端 SDK 判断开关是否命中。规则可以按用户、百分比、地区、时间等维度。客户端要缓存配置、设置默认值，服务端异常时不能影响业务。还要支持一键回滚和定期清理废弃开关。

FB-25-SC-A-010：设计一个前端埋点与监控 SDK 架构

题型：场景设计题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：埋点、监控 SDK、可观测性、数据采集、错误监控 出现频率：高频 预计回答时长：8-12 分钟

题目描述：请设计一个前端埋点与监控 SDK，支持行为埋点、性能指标采集、错误捕获和数据上报。说明 SDK 的模块划分、采集策略和上报机制。

参考答案：前端监控 SDK 应低侵入、高稳定、可扩展，通常分为采集层、处理层、上报层。

架构：

text

┌─────────────────────────────────────┐
│  业务代码：track(event)、异常捕获      │
├─────────────────────────────────────┤
│  采集层：行为 / 性能 / 错误 / 资源      │
├─────────────────────────────────────┤
│  处理层：采样、聚合、脱敏、格式化       │
├─────────────────────────────────────┤
│  上报层：批量、队列、重试、降级         │
├─────────────────────────────────────┤
│  传输：HTTP / Beacon / WebSocket      │
└─────────────────────────────────────┘

模块设计：

行为埋点：自动采集 PV/UV、点击、页面停留；支持手动 track(event, params)。
性能指标：Web Vitals（LCP、FID/INP、CLS）、FCP、TTFB、资源加载时间。
错误监控：监听 window.onerror、unhandledrejection、资源加载失败、框架错误边界。
数据处理：
- 采样：按用户或事件比例采样，降低上报量。
- 聚合：相同错误合并，带首次/最近发生时间。
- 脱敏：过滤敏感字段、截断超长字符串。
上报机制：
- 批量上报：定时或达到一定条数后批量发送。
- 优先使用 navigator.sendBeacon 保证页面关闭时也能发。
- 失败重试，本地队列兜底。

最佳实践：

SDK 初始化应异步加载，不影响首屏。
上报域名应与业务域名分离，避免主域故障时无法上报。
提供服务端采样配置，动态调整采集策略。
关键监控事件走实时通道，普通埋点可延迟聚合。

评分维度：

模块划分（30%）：是否清晰划分采集、处理、上报层
采集覆盖（25%）：是否覆盖行为、性能、错误三类数据
上报可靠性（25%）：是否提到批量、Beacon、重试、队列
性能与隐私（20%）：是否考虑采样、异步加载、脱敏

常见错误：

同步加载大 SDK，阻塞首屏。
每次事件都立即上报，导致请求过多。
采集敏感信息未脱敏，造成隐私风险。

延伸追问：

如果候选人答对了，可追问：页面关闭时如何保证最后一批数据不丢？
如果候选人答错了，可引导：一个用户每点击一次按钮就发一个请求，有什么问题？

相关题目：

FB-25-CO-B-008 什么是事件驱动架构
FB-25-SD-R-007 设计一个跨团队共享的前端能力平台

参考资源：

口头回答版：

前端监控 SDK 一般分为采集层、处理层和上报层。采集层负责行为埋点、性能指标和错误捕获；处理层做采样、聚合和脱敏；上报层负责批量、队列、重试和用 Beacon 发送。SDK 要异步加载，不影响首屏，上报域名最好和业务分开，关键监控实时，普通埋点聚合。

FB-25-SC-A-011：如何设计一个支持多租户的前端应用？

题型：场景设计题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：多租户、SaaS、配置化、品牌化、隔离 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请设计一个支持多租户的 SaaS 前端应用，要求不同租户拥有独立的品牌、菜单、权限和数据视图，同时保持代码复用。

参考答案：多租户前端的核心是"同一份代码、不同配置与数据"，在共享与隔离之间取得平衡。

架构分层：

text

┌─────────────────────────────────────┐
│  租户配置：主题、Logo、文案、功能开关   │
├─────────────────────────────────────┤
│  应用层：统一页面框架、路由、权限       │
├─────────────────────────────────────┤
│  业务层：组件、页面模板                │
├─────────────────────────────────────┤
│  数据层：租户 ID 透传、数据隔离         │
└─────────────────────────────────────┘

关键设计：

租户识别：通过子域名、路径前缀或登录后返回的租户 ID 识别。
配置中心：每个租户维护一份配置，包含品牌、菜单、功能开关、自定义字段。
主题与品牌：使用 CSS 变量或 Design Token，运行时切换。
菜单与路由：根据租户配置动态生成路由和导航。
权限隔离：角色权限模型中增加租户维度，避免跨租户越权。
数据隔离：所有 API 请求自动携带租户 ID，BFF 或服务端做隔离校验。
自定义扩展：保留扩展点，允许租户注入自定义组件或页面片段。

最佳实践：

不要在代码里写死任何租户特例，统一走配置。
对配置做版本管理和缓存，避免每次请求都拉取。
关键业务数据必须服务端校验租户 ID，前端不可信。
提供租户级白名单/黑名单，便于快速开关功能。

评分维度：

租户识别与配置（30%）：是否能通过域名或登录态识别租户并加载配置
隔离设计（25%）：是否覆盖数据隔离、权限隔离、视图隔离
复用能力（25%）：是否强调共享代码、配置化、扩展点
安全与运维（20%）：是否提到服务端校验、配置缓存、版本管理

常见错误：

用 if-else 处理不同租户差异，代码难以维护。
只在前端做租户隔离，服务端不校验租户 ID。
所有租户共用同一份菜单和权限，无法满足个性化。

延伸追问：

如果候选人答对了，可追问：某个租户要求完全定制一个页面，你会怎么做？
如果候选人答错了，可引导：多租户和单纯的白标系统有什么区别？

相关题目：

FB-25-SC-A-009 设计一个前端配置中心
FB-25-SC-P-011 设计一个前端权限架构

参考资源：

口头回答版：

多租户前端就是同一份代码服务多个客户，每个租户有自己的品牌、菜单、权限和数据。实现上通过子域名或租户 ID 识别，加载对应配置；用 CSS 变量换主题；菜单和路由动态生成；权限里加租户维度；所有请求带租户 ID，服务端做隔离校验。不要用 if-else 写死特例，要走配置化。

FB-25-SD-A-012：设计一个前端实时协同编辑系统的架构

题型：系统设计题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：实时协同、CRDT、OT、WebSocket、冲突解决 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个前端实时协同编辑系统，支持多人同时编辑同一文档，说明数据模型、冲突解决策略、同步协议和容错机制。

参考答案：实时协同编辑的核心是在低延迟下保证多个客户端数据最终一致。

整体架构：

text

┌─────────┐   ┌─────────┐   ┌─────────┐
│ Client A│   │ Client B│   │ Client C│
└────┬────┘   └────┬────┘   └────┬────┘
     │             │             │
     └─────────────┼─────────────┘
                   │
            ┌──────┴──────┐
            │ 协同服务器   │
            │ （OT/CRDT）  │
            └─────────────┘

技术选型：

OT（Operational Transformation）：适合文本类场景，依赖中央服务器转换操作。
CRDT（Conflict-free Replicated Data Type）：更适合去中心化、离线场景，本地即可合并。
前端可基于 Yjs、Automerge 等库快速实现 CRDT。

数据模型：

文档由一系列不可变操作或 CRDT 状态组成。
每个操作带作者 ID、时间戳/逻辑时钟、唯一操作 ID。

冲突解决：

OT：服务器按接收顺序转换操作再广播。
CRDT：基于数据结构语义自动合并，如 LWW（Last-Writer-Wins）或自定义合并函数。

同步协议：

使用 WebSocket 传输操作。
断线后重连时同步缺失操作或全量快照。
心跳与 ACK 机制保证消息可靠。

容错机制：

本地持久化草稿，防止数据丢失。
操作去重：唯一操作 ID 避免重复应用。
服务端定时快照，便于快速恢复。

最佳实践：

对光标、选区等临时状态单独同步，避免频繁写文档。
权限控制到段落或字段级，防止越权编辑。
提供冲突提示 UI，让用户感知自动合并结果。

评分维度：

技术选型（25%）：能否比较 OT 与 CRDT 并给出选型依据
数据模型（25%）：是否设计操作/状态模型与唯一 ID
同步与容错（25%）：是否考虑 WebSocket、断线重连、去重、快照
工程落地（25%）：是否提到光标同步、权限、冲突 UI

常见错误：

直接用轮询实现实时编辑，延迟和冲突都很大。
忽略离线编辑场景，断线即不可用。
认为 CRDT 不需要服务器，忽视信令和权限控制。

延伸追问：

如果候选人答对了，可追问：如果两个用户同时修改同一行，CRDT 会怎么处理？
如果候选人答错了，可引导：实时协同和简单的聊天消息同步有什么不同？

相关题目：

FB-25-CO-B-008 什么是事件驱动架构
FB-25-SD-P-008 设计一个金融级前端安全收银台

参考资源：

口头回答版：

实时协同编辑要保证多人同时改一份文档最终一致。技术上可以选 OT，适合文本，需要中央服务器转换操作；也可以选 CRDT，适合去中心化和离线场景，本地能自动合并。数据模型里每个操作要有作者、时钟和操作 ID。同步用 WebSocket，断线后补操作或快照，还要做去重。光标、选区要单独同步，权限控制到字段级。

FB-25-CO-A-013：模块化、组件化、服务化之间有什么区别与联系？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：模块化、组件化、服务化、职责拆分、复用 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请解释模块化、组件化、服务化的概念，说明三者的关注点和相互关系，并举例说明前端如何实践。

参考答案：三者都是拆分复杂系统的手段，但关注点不同。

概念	关注点	前端体现
模块化	按功能或职责拆分代码单元	ES Module、npm 包、业务模块
组件化	把 UI 拆分为独立、可复用的视觉单元	React/Vue 组件、设计系统
服务化	把业务能力封装为独立部署/运行的服务	BFF、微前端子应用、能力平台

关系：

组件化是 UI 维度的模块化。
服务化是更高层次的模块化，强调独立部署和团队自治。
良好的模块化是组件化和服务化的基础。

前端实践：

模块化：按业务域拆分 modules/order、modules/user，每个模块有独立的 api、domain、components。
组件化：把按钮、表单、表格等抽成通用组件，统一在 Design System 中管理。
服务化：大型业务拆分为微前端子应用或 BFF 服务，各自独立发布。

演进路径：

text

单体应用 → 模块化拆分 → 组件库沉淀 → 服务化 / 微前端

最佳实践：

不要为了追求服务化而 prematurely 拆分，先做好模块化和组件化。
明确每一层的边界和依赖方向。
用 Monorepo 或 npm 包管理可复用模块。

评分维度：

概念区分（40%）：能否分别解释模块化、组件化、服务化
关系梳理（30%）：能否说明三者的层次关系
前端实践（30%）：能否结合代码组织、组件库、微前端举例

常见错误：

把组件化等同于模块化，忽略业务模块和服务的划分。
一开始就服务化拆分，导致集成复杂。
模块之间没有明确边界，只是物理上分文件夹。

延伸追问：

如果候选人答对了，可追问：一个组件库属于组件化还是模块化？
如果候选人答错了，可引导：模块化和服务化最大的区别是什么？

相关题目：

FB-25-CO-B-004 前端应用拆分有哪些常见策略
FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层

参考资源：

口头回答版：

模块化是按功能拆分代码单元，组件化是 UI 层面的模块化，把界面拆成可复用的组件，服务化是更高层次的拆分，强调独立部署和团队自治。前端里，业务模块是模块化，组件库是组件化，微前端子应用或 BFF 是服务化。一般先做好模块化和组件化，再考虑服务化。

FB-25-EN-A-014：前端如何实现自动化回归与架构守护？

题型：工程化题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：自动化回归、架构守护、dependency-cruiser、CI、测试 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端自动化回归测试和架构守护的目的、常用工具和落地方法，并举例说明如何防止架构退化。

参考答案：自动化回归确保代码变更不破坏已有功能；架构守护确保代码结构不违反预设的依赖规则。

自动化回归：

单元测试：Jest / Vitest 验证纯函数和 Hook。
集成测试：React Testing Library 验证组件交互。
E2E 测试：Playwright / Cypress 验证核心用户链路。
视觉回归：Chromatic / Playwright 截图对比防止 UI 退化。
快照测试：锁定复杂数据结构或组件输出。

架构守护：

依赖分析：dependency-cruiser、Nx graph 检测循环依赖、跨域引用。
目录约定：通过 CI 校验文件位置是否符合 DDD 分层。
Lint 规则：ESLint 禁止跨层 import、限制某些 API 使用。
ArchUnit 风格测试：写测试断言模块依赖关系。

示例：防止业务模块直接引用另一个业务模块内部：

javascript

// dependency-cruiser 规则
{
  name: 'no-cross-module-internal',
  from: { path: '^src/modules/([^/]+)/' },
  to: { path: '^src/modules/([^/]+)/', pathNot: '^src/modules/$1/' }
}

最佳实践：

回归测试分层建设，核心链路必须有 E2E 覆盖。
架构守护纳入 CI，失败即阻塞合并。
定期 review 依赖图，识别隐式耦合和上帝模块。
把架构规则文档化，方便新人理解。

评分维度：

回归覆盖（40%）：能否说出单元、集成、E2E、视觉回归等多层测试
架构守护工具（30%）：是否提到 dependency-cruiser、Nx、ESLint 等
落地方法（30%）：是否说明 CI 阻塞、规则文档化、定期 review

常见错误：

只写单元测试，忽略集成和 E2E。
架构规则靠口头约定，没有工具守护。
回归测试运行太慢，团队不愿执行。

延伸追问：

如果候选人答对了，可追问：如何防止新同学把 utils 直接 import 到不该去的地方？
如果候选人答错了，可引导：业务域之间互相引用会导致什么问题？

相关题目：

FB-25-CO-B-007 可维护性、可扩展性、可测试性
FB-25-EN-A-004 Monorepo 中如何设计包依赖和版本策略

参考资源：

口头回答版：

自动化回归就是通过各种测试保证改动不破坏功能，包括单元测试、集成测试、E2E、视觉回归。架构守护是用工具保证代码结构不腐烂，比如 dependency-cruiser 检测循环依赖、Nx 检测模块边界、ESLint 限制跨层引用。这些都要进 CI，失败就阻塞合并，还要定期 review 依赖图。

FB-25-CP-A-015：如何处理遗留系统的渐进式重构？

题型：综合开放题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：遗留系统、渐进式重构、绞杀者模式、技术债、迁移 出现频率：高频 预计回答时长：8-12 分钟

题目描述：请描述在面对一个大型遗留前端系统时，如何制定渐进式重构策略，平衡业务交付与架构演进。

参考答案：遗留系统重构的关键是控制风险、持续交付价值，而不是一次性重写。

核心策略：

现状评估
- 梳理核心业务流程、技术债务、依赖关系、测试覆盖。
- 识别热点：改动最频繁、bug 最多、性能最差的部分优先重构。
建立安全网
- 补充核心链路 E2E 测试，确保重构不破坏业务。
- 增加监控和告警，快速发现回归。
绞杀者模式（Strangler Fig）
- 新功能用新架构实现，通过适配层与遗留系统共存。
- 逐步用新模块替换旧模块，而不是一次性推翻。
增量迁移路径
- 按路由、业务域或页面逐步迁移。
- 每次只改一小块，保持可回滚。
接口适配与防腐层
- 旧系统与新系统之间通过适配器交互。
- 避免新代码直接依赖旧系统的内部实现。
度量与沟通
- 设定重构目标：构建时间、测试覆盖率、循环依赖数等。
- 向业务方透明进度，争取合理的重构窗口。

最佳实践：

不要承诺"重写一次解决所有问题"。
重构必须与业务需求结合，避免纯技术重构项目。
保留旧系统入口，支持灰度切换和快速回滚。

评分维度：

策略完整性（35%）：是否覆盖评估、安全网、绞杀者、增量迁移
风险意识（30%）：是否强调测试、监控、回滚、灰度
业务平衡（20%）：是否提到与业务需求结合、透明沟通
度量能力（15%）：是否提出可量化的重构指标

常见错误：

直接全盘重写，导致长时间无法交付。
没有测试覆盖就重构， bug 层出不穷。
只重构技术层，不解决业务痛点。

延伸追问：

如果候选人答对了，可追问：业务方要求两个月上线大需求，你怎么安排重构？
如果候选人答错了，可引导：遗留系统里一个模块耦合严重，但又不能停业务，你会怎么做？

相关题目：

FB-25-CP-P-004 如何做一次技术选型决策并沉淀 ADR
FB-25-EN-P-007 前端架构从单体到微前端再到模块化

参考资源：

口头回答版：

处理遗留系统要用渐进式重构，不要一次性重写。先评估现状、建立安全网，比如补 E2E 测试和监控；然后用绞杀者模式，新功能用新架构做，通过适配层和老系统共存，逐步替换。每次只改一小块，保持可回滚。重构要跟业务需求结合，不要纯技术驱动。

FB-25-PE-A-016：从架构角度设计一个首屏加载优化方案

题型：性能优化题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：首屏优化、SSR、SSG、流式、预加载、架构 出现频率：高频 预计回答时长：8-12 分钟

题目描述：请从架构层面设计一个首屏加载优化方案，覆盖网络、渲染、资源加载和运行时多个层次。

参考答案：首屏加载优化需要在网络、构建、服务端、客户端多个层次协同。

优化层次：

网络层
- CDN 边缘缓存静态资源，缩短传输距离。
- Brotli / Gzip 压缩，减少体积。
- HTTP/2 或 HTTP/3 多路复用，减少队头阻塞。
- 域名分片与连接优化。
构建层
- 代码分割：路由级、组件级懒加载。
- Tree Shaking 和死代码消除。
- 第三方库按需引入或替换为轻量实现。
- 公共资源长期缓存（hash 文件名）。
服务端渲染层
- SSR：首屏由服务端生成 HTML，减少客户端等待。
- SSG：内容型页面预渲染为静态 HTML。
- 流式渲染：边生成边传输，提升 TTFB 和 FCP。
- 边缘渲染：在 CDN 节点运行渲染逻辑。
客户端渲染层
- 关键 CSS 内联，非关键 CSS 异步加载。
- 图片懒加载、响应式图片、WebP/AVIF。
- 字体优化：font-display、子集化、预加载。
- 骨架屏提升感知性能。
预加载策略
- 对下一页资源使用 <link rel="preload"> / <link rel="prefetch">。
- 服务端推送或 Early Hints（103）。

架构保障：

建立性能基线，CI 中监控 LCP、FCP、TTFB。
使用 RUM + APM 持续追踪真实用户数据。

最佳实践：

先测量再优化，避免盲目拆分。
关键链路优先，非关键资源延后。
兼顾低性能设备，做降速测试。

评分维度：

层次覆盖（40%）：是否覆盖网络、构建、服务端、客户端四层
技术方案（30%）：能否具体说出 SSR、流式、懒加载、预加载等手段
可度量性（20%）：是否提到 Web Vitals 和 CI 基线
兼顾性（10%）：是否考虑低端设备和感知性能

常见错误：

只压缩 JS，不优化渲染路径。
过度拆分导致请求数过多。
没有性能基线，无法验证优化效果。

延伸追问：

如果候选人答对了，可追问：SSR 和 SSG 在架构上分别适合什么场景？
如果候选人答错了，可引导：首屏慢，你先从哪个指标入手分析？

相关题目：

FB-25-PE-A-006 从架构视角看性能优化如何系统化思考
FB-25-EN-B-015 如何分析前端构建产物

参考资源：

口头回答版：

首屏优化要从网络、构建、服务端和客户端一起搞。网络上用 CDN、压缩、HTTP2；构建上做代码分割、Tree Shaking、按需加载；服务端用 SSR、SSG、流式渲染；客户端内联关键 CSS、图片懒加载、字体优化、骨架屏。还要设性能基线，监控 LCP、FCP 这些指标。

FB-25-SE-A-017：从架构角度看，前端供应链安全应该如何设计？

题型：安全题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：25 系统架构设计标签：供应链安全、依赖治理、SAST、SCA、SBOM、npm 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请从架构层面说明前端供应链安全的风险点和防护体系，包括依赖管理、构建安全和发布安全。

参考答案：前端供应链安全关注从开源依赖、构建工具到部署交付全链路的安全。

风险点：

依赖风险：恶意 npm 包、过期依赖、权限过大的 postinstall 脚本。
仓库风险：GitHub 凭据泄露、依赖锁定文件被篡改。
构建风险：构建机被入侵、构建产物被注入恶意代码。
分发风险：CDN 被劫持、版本回退攻击。

防护体系：

层次	措施
依赖治理	锁定版本、私有仓库、依赖审计（npm audit / Snyk）
漏洞扫描	SCA 工具扫描依赖 CVE、生成 SBOM
静态分析	SAST 检测代码中的危险 API、硬编码密钥
构建安全	隔离构建环境、签名产物、Reproducible Build
发布安全	权限最小化、双审批、回滚策略
运行时安全	CSP、SRI、子资源完整性校验

架构实践：

使用 pnpm / npm workspaces 并启用 ignore-scripts 限制 postinstall。
CI 中运行 npm audit --audit-level=moderate 并阻塞高危漏洞。
对关键依赖做源码审查或 pin 到具体版本。
产物上传前计算 hash，部署时校验。

最佳实践：

建立依赖白名单和升级窗口，避免随意引入新包。
定期进行依赖清理，移除无用依赖。
将安全扫描前置到 MR/PR 阶段，左移安全。

评分维度：

风险识别（30%）：能否列出依赖、构建、分发等供应链风险
防护措施（40%）：是否覆盖 SCA、SAST、SBOM、CSP、SRI 等
工程落地（20%）：是否提到 CI 集成、依赖锁定、产物签名
治理意识（10%）：是否提到白名单、升级窗口、左移

常见错误：

只关注运行时 XSS，忽略依赖和构建环节。
使用 * 或 ^ 版本范围却不审计。
postinstall 脚本随意执行，增加被攻击面。

延伸追问：

如果候选人答对了，可追问：发现某个依赖有 CVE 但业务紧急，你会怎么处理？
如果候选人答错了，可引导：npm 包的 postinstall 脚本可能带来什么风险？

相关题目：

FB-25-SE-A-007 从架构视角看前端安全应该如何设计
FB-25-SD-P-008 设计一个金融级前端安全收银台

参考资源：

口头回答版：

前端供应链安全要从依赖、构建、分发全链路防护。依赖上要锁定版本、审计 CVE、生成 SBOM；构建上要隔离环境、签名产物；分发上要用 CSP、SRI 校验。CI 里跑 npm audit、SAST、SCA，高危漏洞阻塞合并。还要控制 postinstall 脚本，定期清理无用依赖。

深入题（16 道）

FB-25-SD-P-001：设计一个低代码/搭建平台的前端架构

题型：系统设计题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计、52 低代码 / 搭建标签：低代码、搭建平台、Schema 驱动、渲染引擎、物料 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个低代码/搭建平台的前端架构，支持通过拖拽和配置生成 H5/PC/小程序页面。要求覆盖物料体系、Schema 协议、渲染引擎、数据流、扩展能力等核心模块。

参考答案：

整体架构

text

┌─────────────────────────────────────────┐
│              设计器（Designer）           │
│  画布 / 组件库 / 属性面板 / 大纲树 / 数据源配置 │
└───────────────┬─────────────────────────┘
                │  页面 Schema（JSON）
┌───────────────┴─────────────────────────┐
│              渲染引擎（Runtime）          │
│  Schema Parser / 组件映射 / 状态管理 / 事件编排  │
└───────────────┬─────────────────────────┘
                │
┌───────────────┴─────────────────────────┐
│              物料中心（Materials）        │
│  基础组件 / 业务组件 / 模板 / 自定义扩展     │
└─────────────────────────────────────────┘

Schema 协议
- 页面 Schema 描述组件树、属性、样式、事件、数据源。

json

{
  "type": "Page",
  "props": { "title": "营销活动" },
  "children": [
    {
      "type": "Banner",
      "props": { "src": "&#123;&#123;$data.bannerUrl&#125;&#125;" },
      "events": { "onClick": "&#123;&#123;$action.openLink&#125;&#125;" }
    }
  ],
  "dataSources": {
    "bannerUrl": { "type": "api", "url": "/api/banner" }
  }
}

使用 JSON Schema 对物料和页面 Schema 做校验。
支持表达式 {{}}，在运行时解析为数据绑定或函数。

物料体系
- 物料 = 组件 + 配置描述（meta）。
- meta 包含：组件名、图标、属性面板配置、默认数据、版本、依赖。
- 物料注册：设计器和渲染引擎共用同一份物料描述。
渲染引擎
- Parser：把 Schema 解析为组件树。
- Resolver：根据 type 映射到真实组件实现。
- Renderer：递归渲染，处理条件、循环、插槽。
- Expression Engine：解析 {{}} 表达式，访问状态和上下文。
- Event Bus：把 Schema 中定义的事件绑定到实际处理器。
数据流与状态管理
- 页面级状态：变量、URL 参数、全局上下文。
- 数据源：API、Mock、跨页面共享。
- 设计器和运行时使用同一套状态模型。
扩展能力
- 自定义物料：按约定注册新组件。
- 自定义事件动作：如跳转、埋点、调用原生能力。
- 插件机制：设计器插件、属性面板扩展。
多端输出
- Schema 与具体渲染层解耦。
- 同一 Schema 可渲染为 Web（React/Vue）、小程序、RN 等不同端。

最佳实践：

Schema 是核心资产，版本化存储，支持 diff 和回滚。
设计器和渲染引擎共用协议，避免“设计时和运行时两套逻辑”。
复杂逻辑允许“低代码 + 高代码”混合：通过自定义脚本或组件扩展。

评分维度：

架构完整性（30%）：是否覆盖设计器、渲染引擎、物料、Schema 等核心模块
Schema 设计（25%）：是否定义合理的页面描述协议
扩展性（20%）：是否支持自定义物料、事件、插件
多端能力（15%）：是否考虑 Schema 与渲染层解耦
数据流（10%）：是否说明状态管理和数据源设计

常见错误：

只设计拖拽界面，忽略 Schema 协议和渲染引擎的分离。
把低代码平台做成“配置化表单生成器”，无法支持复杂页面。
设计器和运行时逻辑重复，导致上线后与设计时不一致。

延伸追问：

如果候选人答对了，可追问：如何保证设计器里的效果和运行时一致？
如果候选人答错了，可引导：低代码平台最核心的“协议”是什么？

相关题目：

FB-25-SC-P-002 设计一个 SDUI 系统
FB-25-SC-R-003 设计一个大型电商活动搭建平台前端架构

参考资源：

口头回答版：

低代码平台核心是分三层：设计器、渲染引擎、物料中心。设计器负责拖拽和配置，输出页面 Schema；渲染引擎解析 Schema 并渲染真实组件；物料中心管理基础组件、业务组件和模板。Schema 要定义清楚组件树、属性、事件、数据源，最好用 JSON Schema 校验。渲染引擎要有 Parser、Resolver、表达式引擎、事件总线。还要支持自定义物料和扩展，设计器和运行时要共用同一套协议，保证所见即所得。同一套 Schema 可以输出到不同端。

FB-25-SC-P-002：设计一个 SDUI（Server-Driven UI）系统

题型：场景设计题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：SDUI、Server-Driven UI、动态化、配置下发 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个 SDUI 系统，服务端下发页面配置，客户端根据配置渲染界面。要求说明配置协议、客户端渲染流程、缓存策略、降级方案。

参考答案：

整体流程

text

服务端（CMS / 配置平台）
    │
    ▼
生成页面配置 JSON
    │
    ▼
下发到客户端（Web / App / 小程序）
    │
    ▼
客户端解析配置 → 映射组件 → 请求数据 → 渲染页面

配置协议设计
- 页面配置包含：版本号、组件树、数据源、样式主题、实验标记。

json

{
  "version": "1.2.0",
  "theme": "default",
  "components": [
    {
      "type": "Carousel",
      "id": "banner_001",
      "props": { "height": 200 },
      "data": { "source": "api:/banners", "field": "list" }
    },
    {
      "type": "ProductGrid",
      "id": "products_001",
      "props": { "columns": 2 },
      "data": { "source": "api:/recommend" }
    }
  ]
}

客户端渲染流程
- 配置拉取：启动时或页面进入时拉取配置，带版本号做缓存校验。
- Schema 校验：校验配置合法性，避免非法组件或字段导致崩溃。
- 组件映射：根据 type 查找本地注册的组件实现。
- 数据请求：按配置中的 data.source 发起请求，绑定到组件。
- 渲染与事件处理：递归渲染组件树，处理点击、跳转、埋点等事件。
缓存策略
- 配置缓存：本地缓存最新配置，服务端未更新时直接使用。
- 数据缓存：组件级数据缓存，避免重复请求。
- 版本控制：配置带版本号，客户端按版本增量更新。
降级方案
- 配置解析失败：使用兜底静态页面或上次可用配置。
- 组件未注册：跳过该组件，不影响整体页面。
- 数据请求失败：显示占位图或默认数据。
- 版本不兼容：客户端版本过低时提示升级或返回兼容配置。
关键设计点
- 组件原子化：服务端只描述“有什么”，具体样式和交互在客户端实现。
- 灰度与 AB 实验：配置中可携带实验标记，客户端按标记分流。
- 安全性：校验所有下发字段，禁止执行动态脚本（除非有沙箱）。

最佳实践：

配置协议版本化，客户端和服务端约定兼容规则。
优先用本地组件渲染，不要用 WebView 动态加载远程脚本。
监控配置解析成功率和组件渲染异常。

评分维度：

协议设计（25%）：配置协议是否合理、可扩展
渲染流程（25%）：是否完整说明从拉取到渲染的步骤
缓存与降级（25%）：是否设计配置缓存、数据缓存、多级降级
安全与灰度（15%）：是否提到校验、沙箱、AB 实验
组件化思维（10%）：是否区分服务端描述与客户端实现

常见错误：

把 SDUI 等同于“服务端返回 HTML 字符串”，失去组件化和缓存优势。
下发可执行脚本而不做沙箱隔离，带来 XSS 风险。
没有版本控制，新配置导致旧客户端崩溃。

延伸追问：

如果候选人答对了，可追问：SDUI 和低代码平台有什么区别和联系？
如果候选人答错了，可引导：服务端下发的配置和客户端组件怎么对应？

相关题目：

FB-25-SD-P-001 设计一个低代码平台前端架构
FB-25-SC-R-003 设计一个大型电商活动搭建平台前端架构

参考资源：

口头回答版：

SDUI 就是服务端下发页面配置，客户端根据配置渲染界面。流程是服务端在 CMS 里生成配置 JSON，客户端拉取后做 Schema 校验，然后按 type 映射到本地组件，请求数据，渲染出来。缓存方面可以本地缓存配置和数据，按版本号增量更新。降级要考虑配置解析失败用兜底、组件未注册跳过、数据失败用占位、版本不兼容提示升级。关键是服务端只描述有什么，具体组件实现和样式在客户端。

FB-25-CO-P-003：整洁架构（Clean Architecture）和六边形架构（Hexagonal Architecture）如何在前端落地？

题型：概念题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：整洁架构、六边形架构、依赖倒置、分层、端口适配器 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请解释整洁架构和六边形架构的核心思想，并说明如何在前端项目中落地，避免业务逻辑与框架、UI、API 实现耦合。

参考答案：

核心思想：

依赖倒置原则：内层（业务）不依赖外层（框架、UI、数据库/API），外层依赖内层。
分层：中心是领域实体和业务规则，外层是接口适配器、框架、UI。
端口与适配器：内层定义端口（接口），外层提供适配器（实现）。

前端分层映射：

text

┌─────────────────────────────────────┐
│  UI 层（React/Vue Components）       │  外层
├─────────────────────────────────────┤
│  应用层（Hooks / Use Cases）         │  接口适配器层
├─────────────────────────────────────┤
│  领域层（Entities / Domain Services）│  内层
├─────────────────────────────────────┤
│  基础设施层（API / Storage / Logger）│  外层
└─────────────────────────────────────┘

落地示例：

typescript

// 内层：领域层，不依赖框架
export interface OrderRepository {
  findById(id: string): Promise<Order>;
}

export function calculateOrderTotal(order: Order): Money {
  return order.items.reduce((sum, item) => sum.add(item.price), Money.zero());
}

// 外层：基础设施适配器
export class HttpOrderRepository implements OrderRepository {
  async findById(id: string): Promise<Order> {
    const dto = await fetch(`/api/orders/${id}`).then(r => r.json());
    return mapDtoToOrder(dto);
  }
}

// 应用层：Hook
export function useOrder(id: string) {
  const repository = useContainer().resolve<OrderRepository>('OrderRepository');
  return useQuery({ queryKey: ['order', id], queryFn: () => repository.findById(id) });
}

关键落地原则：

领域层只包含纯函数和接口，不 import React/Vue/axios。
依赖注入：通过 IoC 容器把外层适配器注入到应用层。
防腐层：API 层做 DTO 到领域模型的映射。
单向依赖：UI 层 → 应用层 → 领域层，领域层不依赖外层。

适用场景：

业务逻辑复杂、长期演进的系统，如金融、电商后台。
需要频繁切换技术栈或框架的系统。

最佳实践：

不要一次性重构整个项目，可以从新模块开始试点。
用 dependency-cruiser 检查违规依赖。
领域模型优先用 TypeScript 类型表达，避免过度面向对象。

评分维度：

核心思想理解（35%）：能否解释依赖倒置、分层、端口适配器
前端映射（35%）：能否把分层对应到 UI、应用、领域、基础设施
落地能力（20%）：是否给出代码示例或依赖检查方法
场景判断（10%）：是否知道何时该用、何时不必用

常见错误：

把业务逻辑直接写在组件里，领域层沦为空壳。
过度设计，为简单 CRUD 系统引入复杂 IoC 容器。
依赖方向反向，领域层 import React Hook。

延伸追问：

如果候选人答对了，可追问：如果项目已经在 React 里写了大量业务逻辑，如何逐步迁移到整洁架构？
如果候选人答错了，可引导：整洁架构最核心的一条规则是什么？

相关题目：

FB-25-CO-A-003 DDD 中的核心概念如何映射到前端架构
FB-25-SC-P-005 设计一个插件化的前端应用

参考资源：

口头回答版：

整洁架构和六边形架构核心都是依赖倒置：内层是业务规则，外层是 UI、框架、API 这些实现，外层依赖内层，内层不依赖外层。前端落地可以分成 UI 层、应用层、领域层、基础设施层。领域层只放纯业务和接口，不 import React 或 axios；应用层用 Hook 调用领域服务；基础设施层做 HTTP 适配和 DTO 转换。通过依赖注入把实现注入进去。这样换框架或换 API 方案时，业务逻辑不用大改。

FB-25-CP-P-004：你所在团队要引入一个新的前端框架或工具链，请描述完整的决策过程

题型：综合开放题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：技术选型、决策流程、PoC、ADR、风险评估 出现频率：中频 预计回答时长：8-12 分钟

题目描述：假设团队目前使用 Vue 2 + Webpack，考虑迁移到 Vue 3 + Vite。请描述你会如何推动这个技术决策，包括评估、验证、沟通和落地步骤。

参考答案：

完整决策过程：

问题定义
- 明确痛点：构建慢、Vue 2 停止维护、TypeScript 支持弱。
- 设定成功指标：构建时间降低 50%、类型覆盖率提升到 80%、升级后线上故障数 < 2。
约束与风险识别
- 团队规模与 Vue 3 熟悉度。
- 存量业务代码量、第三方库兼容性。
- 交付压力：是否允许暂停业务开发。
候选方案对比

方案	优点	缺点
A. 直接迁移到 Vue 3 + Vite	技术栈统一，长期收益大	风险高、周期长
B. 渐进式迁移，先新模块用 Vue 3	风险低、可回退	维护两套技术栈
C. 只升级 Vite，保留 Vue 2	构建收益快	Vue 2 维护问题未解决
D. 维持现状	无迁移成本	技术债累积

PoC 验证
- 选一个非核心模块做 Vue 3 + Vite 试点。
- 验证：构建速度、测试覆盖率、关键第三方库兼容性、开发者体验。
- 输出 PoC 报告，量化收益和风险。
决策与 ADR
- 召集利益相关者评审：前端组长、QA、SRE、产品经理。
- 形成 ADR，记录选择方案 B 的理由、风险、回滚策略。
沟通与落地
- 制定迁移路线图：试点 → 工具链统一 → 模块分批迁移 → 存量收尾。
- 建立迁移手册、培训、代码模板。
- 每个阶段设置验收标准和回滚点。
度量与复盘
- 监控构建时间、线上错误率、团队满意度。
- 定期复盘，调整迁移节奏。

最佳实践：

技术决策要和业务目标挂钩，避免纯技术自嗨。
永远准备一个“不做”的候选方案。
渐进式迁移通常优于大爆炸式迁移。

评分维度：

流程完整性（30%）：是否覆盖问题定义、评估、PoC、决策、落地、复盘
风险评估（25%）：是否识别业务、技术、人员风险
方案对比（20%）：是否给出多个候选方案并客观对比
沟通与落地（15%）：是否提到利益相关者沟通和迁移路线图
度量意识（10%）：是否设定可量化的成功指标

常见错误：

只看技术指标，忽略业务交付压力和团队学习能力。
决策过程不透明，少数人拍板。
没有回滚方案，一旦出问题难以恢复。

延伸追问：

如果候选人答对了，可追问：如果业务方说没有时间给你迁移，你会怎么说服？
如果候选人答错了，可引导：技术选型中“不做任何改变”为什么也要作为一个方案？

相关题目：

FB-25-CO-B-005 技术选型的一般流程
FB-25-CO-B-006 什么是 ADR

参考资源：

口头回答版：

我会先明确为什么要迁移，比如 Vue 2 停止维护、构建慢，然后定义成功指标。接着列出候选方案：直接迁移、渐进迁移、只升 Vite、维持现状，并从风险、周期、收益对比。选一个非核心模块做 PoC，验证构建速度、兼容性和体验。然后召集相关人评审，形成 ADR。落地上制定路线图，先做试点再分批迁移，每一步有验收和回滚点。最后监控指标和复盘。关键是和业务目标挂钩，渐进迁移比大爆炸安全。

FB-25-SC-P-005：设计一个插件化的前端应用，支持第三方扩展

题型：场景设计题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：插件化、微内核、扩展点、沙箱、生命周期 出现频率：低频 预计回答时长：10-15 分钟

题目描述：请设计一个插件化的前端应用，核心系统提供基础能力，第三方开发者可以开发插件扩展功能。要求说明扩展点设计、插件加载机制、沙箱隔离、版本管理。

参考答案：

整体架构

text

┌─────────────────────────────────────┐
│           插件市场 / 注册中心          │
├─────────────────────────────────────┤
│           核心应用（Core）            │
│  扩展点注册表 / 生命周期管理 / 沙箱    │
├─────────────────────────────────────┤
│  插件 A  │  插件 B  │  插件 C        │
│ 表单扩展 │  图表    │  审批流程       │
└─────────────────────────────────────┘

扩展点（Extension Point）设计
- 核心系统显式声明可扩展的位置和能力。

typescript

interface ExtensionPoint {
  id: string;
  // 扩展点描述
  schema: JSONSchema;
  // 接收扩展贡献
  contributions: Contribution[];
}

常见扩展点：

菜单/路由注册
表单字段类型
页面区块
事件处理器
数据源类型

插件加载机制
- 插件以包（npm/umd）形式发布。
- 核心应用在运行时通过配置或市场动态加载插件。
- 插件注册时声明自己贡献的扩展点。

typescript

const plugin = {
  name: 'chart-plugin',
  activate(context: PluginContext) {
    context.registerField('chart', ChartField);
    context.registerRoute('/charts', ChartPage);
  },
  deactivate() {}
};

沙箱隔离
- JS 隔离：Proxy 沙箱、iframe、Web Worker。
- 样式隔离：Shadow DOM、CSS Modules、动态样式前缀。
- 权限控制：插件只能访问声明的 API，核心 API 白名单化。
生命周期管理
- load → register → activate → run → deactivate → unload。
- 插件异常时单独捕获，不影响核心应用。
版本管理与兼容性
- 插件声明兼容的核心版本范围。
- 核心提供版本化 API，避免 break change 影响插件。
- 插件市场做版本控制和灰度发布。

最佳实践：

核心系统保持精简，通过扩展点生长能力。
插件 API 设计要稳定，变更遵循 Semver。
提供完整的插件开发文档、调试工具和示例。

评分维度：

扩展点设计（30%）：是否显式定义扩展点和贡献机制
加载与生命周期（25%）：是否说明插件注册、激活、卸载流程
沙箱隔离（20%）：是否设计 JS、样式、权限隔离
版本管理（15%）：是否考虑 API 兼容和 Semver
可扩展性（10%）：是否区分核心与插件职责

常见错误：

扩展点设计过死，第三方无法做有意义的扩展。
没有沙箱隔离，插件可以任意修改全局状态。
插件 API 不稳定，每次核心升级都要重写插件。

延伸追问：

如果候选人答对了，可追问：插件之间如果需要通信，你会怎么设计？
如果候选人答错了，可引导：插件化系统和普通组件库有什么区别？

相关题目：

FB-25-CO-B-008 什么是事件驱动架构
FB-25-SD-P-001 设计一个低代码平台前端架构

参考资源：

口头回答版：

插件化系统核心是核心应用加扩展点。核心要显式声明哪些地方可以扩展，比如菜单、表单字段、页面区块。插件以包形式发布，注册时声明贡献哪些扩展点。加载后按生命周期 activate、run、deactivate 管理。沙箱要做好 JS、样式、权限隔离，防止插件破坏核心。API 要稳定，遵循 Semver，插件声明兼容的核心版本。这样核心保持精简，能力靠插件生长。

FB-25-CO-P-006：CQRS 和事件溯源（Event Sourcing）在前端有哪些应用场景？

题型：概念题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计、29 数据与状态管理标签：CQRS、事件溯源、状态管理、命令查询分离 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请解释 CQRS（命令查询职责分离）和事件溯源（Event Sourcing）的基本概念，并说明它们在前端架构中的适用场景和落地方式。

参考答案：

基本概念：

CQRS：把“写操作（Command）”和“读操作（Query）”分离，使用不同的模型或服务处理。
事件溯源：不存储最终状态，而是存储所有改变状态的事件序列，状态可随时重放事件重建。

前端应用场景：

复杂表单/工作流
- Command：提交、保存草稿、撤销、重做。
- Query：表单当前视图、校验状态、历史记录。
- 事件溯源：记录每一次字段修改事件，支持撤销、重做、审计。
协同编辑
- 每个用户操作变成事件（InsertText、DeleteText）。
- 服务端保存事件流，前端根据事件流合并本地状态。
- 典型代表：OT/CRDT 协同编辑器。
购物车/订单状态机
- 事件：AddItem、RemoveItem、ApplyCoupon、Checkout。
- 状态由事件流派生，便于追踪和回放。
前端 DevTools / 时间旅行调试
- Redux DevTools 就是事件溯源思想：记录 action 历史，可回放状态。

前端落地方式：

typescript

// 事件定义
type CartEvent =
  | { type: 'ItemAdded'; payload: { productId: string; qty: number } }
  | { type: 'ItemRemoved'; payload: { productId: string } };

// 折叠事件得到当前状态
function fold(events: CartEvent[]): CartState {
  return events.reduce(applyEvent, initialState);
}

// Command 生成事件
function addItem(productId: string, qty: number): CartEvent {
  return { type: 'ItemAdded', payload: { productId, qty } };
}

权衡：

优势：状态可追溯、支持撤销重做、调试方便、便于审计。
劣势：复杂度高、事件版本管理困难、存储和性能开销大。

最佳实践：

不要在所有状态上都用事件溯源，只用于核心、变化频繁、需要审计的状态。
给事件加版本号，支持事件 schema 演进。
定期快照（snapshot）减少重放事件数量。

评分维度：

概念准确性（35%）：能否准确解释 CQRS 和事件溯源
前端场景（35%）：能否给出表单、协同、购物车等具体场景
落地能力（20%）：是否给出事件定义、折叠函数等代码示例
权衡意识（10%）：是否提到复杂度、事件版本、快照

常见错误：

把 CQRS 等同于“读写分离数据库”，忽略前端读模型和写模型分离。
认为事件溯源适合所有状态管理场景。
忽视事件版本兼容和快照机制。

延伸追问：

如果候选人答对了，可追问：Redux 是不是 CQRS？Redux DevTools 是不是事件溯源？
如果候选人答错了，可引导：如果一个表单支持撤销 100 步，你会怎么存储状态？

相关题目：

FB-25-CO-B-008 什么是事件驱动架构
FB-25-SD-P-001 设计一个低代码平台前端架构

参考资源：

口头回答版：

CQRS 是把读和写分开，用不同模型处理；事件溯源是不存最终状态，而是存所有改变状态的事件，状态可以重放事件重建。前端里适合用在复杂表单 undo/redo、协同编辑、购物车状态机、Redux DevTools 时间旅行这些场景。落地时定义事件类型，用 reduce 折叠事件得到当前状态，Command 负责生成事件。但不是所有状态都要事件溯源，核心且需要审计的状态才用，还要做版本号和快照。

FB-25-EN-P-007：描述一个前端架构从单体应用到微前端再到模块化架构的演进过程

题型：工程化题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计、26 微前端标签：架构演进、单体、微前端、模块化、迁移 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请描述一个前端系统从单体应用逐步演进到微前端，再到更轻量的模块化架构的过程，说明每个阶段的痛点、解决方案和回退策略。

参考答案：

演进三阶段：

阶段一：单体应用
- 特征：一个仓库、统一技术栈、所有业务代码耦合。
- 痛点：构建慢、发布互相阻塞、代码冲突多。
- 解药：
  - 业务模块化：按业务域拆分目录，明确模块边界。
  - 公共库抽离：组件库、工具库独立包。
  - 路由懒加载：按路由拆分 chunk。
阶段二：微前端
- 触发条件：团队规模扩大、需要独立部署、技术栈不完全一致。
- 方案：引入 qiankun/Module Federation，按团队或业务域拆分子应用。
- 收益：团队自治、独立部署、风险隔离。
- 新痛点：
  - 运行时复杂度高。
  - 公共依赖重复或版本冲突。
  - 子应用间通信和状态共享困难。
  - 发布和回滚协调变复杂。
阶段三：模块化架构（Monorepo + 组件化 + 可选微前端）
- 触发条件：团队成熟、技术栈统一、希望降低运行时复杂度。
- 方案：
  - 使用 Monorepo 组织业务包和共享包。
  - 业务模块作为可复用包，通过 npm/workspace 引用。
  - 保留一个轻量“壳应用”做路由和公共能力，必要时再嵌入微前端。
  - 构建时拆分替代运行时拆分，减少微前端开销。
- 收益：
  - 编译时依赖清晰，便于重构和测试。
  - 构建产物可控，性能更好。
  - 团队仍可按包独立发布。

演进路径图：

text

单体应用
   │
   ▼  业务模块化 + 公共库抽离 + 路由懒加载
中粒度单体
   │
   ▼  独立部署需求强烈
微前端
   │
   ▼  团队成熟、技术栈统一、降本增效
模块化 / Monorepo + 轻量壳应用

回退策略：

每个阶段保留可独立运行的旧版本入口。
模块边界清晰，便于从微前端回退到 Monorepo 包依赖。
数据层统一，避免子应用数据孤岛。

最佳实践：

不要为了微前端而微前端，它是组织协作问题的解。
演进目标是从“物理隔离”走向“逻辑隔离 + 按需聚合”。
架构师要根据团队规模、发布节奏、技术栈成熟度做决策。

评分维度：

阶段理解（30%）：能否清晰描述单体、微前端、模块化三阶段
痛点识别（25%）：能否说出每个阶段的核心痛点
演进逻辑（20%）：演进是否符合业务发展规律
回退意识（15%）：是否提到回退策略和版本兼容
落地经验（10%）：是否结合实际项目经验举例

常见错误：

认为微前端是最终形态，忽略模块化回退。
把演进当成线性过程，不考虑组织实际情况。
忽视数据层和公共能力在演进中的稳定性。

延伸追问：

如果候选人答对了，可追问：你们团队现在处于哪个阶段？下一步演进方向是什么？
如果候选人答错了，可引导：微前端解决了什么问题，又带来了什么问题？

相关题目：

FB-25-CO-A-008 微前端有哪些实现方式
FB-25-EN-A-004 Monorepo 中如何设计包依赖和版本策略

参考资源：

口头回答版：

演进一般分三步。一开始是单体应用，所有代码放一起，构建慢、发布互相影响。先通过业务模块化、抽公共库、路由懒加载来优化。团队大了之后，为了独立部署上微前端，按团队或业务拆子应用，但运行时会变复杂，公共依赖和通信也麻烦。最后团队成熟、技术栈统一了，可以转向 Monorepo 模块化架构，业务模块作为包被壳应用引用，构建时拆分，性能更好，必要时再保留微前端能力。演进不是线性的，要看组织情况，数据层要稳定，回退策略也要考虑。

FB-25-SD-P-008：设计一个金融级前端安全收银台架构

题型：系统设计题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：金融、收银台、安全架构、风控、加密、合规 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个金融级前端收银台，要求支持多种支付方式、风控校验、防篡改和敏感信息保护，并说明安全加固和降级策略。

参考答案：金融收银台对安全、稳定和合规要求极高，必须在可信环境中处理敏感数据。

整体架构：

text

用户 → 收银台 H5/Web → API Gateway → BFF → 支付核心/风控/渠道
                ↓
           安全 SDK（加密、风控、环境检测）

核心设计：

输入安全
- 敏感输入框使用安全键盘或 Native 组件，防止键盘劫持。
- 密码、CVV 等字段前端不缓存，输入即加密。
- 使用 RSA/AES 混合加密，结合服务端公钥。
防篡改
- 关键 JS/CSS 使用 SRI（Subresource Integrity）校验。
- 运行时代码完整性校验，检测 DOM/JS 注入。
- CSP 限制外部脚本执行。
风控与身份
- 设备指纹、行为生物特征（滑动轨迹、按键节奏）。
- 支付前风控评分，异常触发二次验证或拒绝。
- Token 短时效，关键操作需短信/人脸/U盾确认。
通道与降级
- 多支付渠道路由，单一渠道失败自动切换。
- 核心支付链路异步化，超时后主动查询订单状态。
- 降级方案：静态收银台、人工客服、延迟支付。
合规与审计
- 日志脱敏，敏感字段不上报。
- 全链路追踪，支持风控回溯。
- 符合 PCI-DSS、等保等规范。

最佳实践：

收银台页面使用独立域名，隔离业务系统 XSS 风险。
关键逻辑下沉到服务端，前端仅做展示和触发。
上线前必须通过渗透测试和代码审计。

评分维度：

安全设计（35%）：是否覆盖加密、防篡改、输入安全、风控
架构完整性（25%）：是否说明 Gateway、BFF、风控、渠道的分层
稳定性（20%）：是否有多渠道路由、超时查询、降级策略
合规意识（20%）：是否提到 PCI-DSS、日志脱敏、审计

常见错误：

敏感信息以明文形式存储或传输。
所有支付逻辑放在前端，容易被绕过。
只关注功能，忽略风控和合规要求。

延伸追问：

如果候选人答对了，可追问：如果用户浏览器被注入了恶意脚本，你能做什么防护？
如果候选人答错了，可引导：为什么支付密码不建议用普通 input 框输入？

相关题目：

FB-25-SE-A-007 从架构视角看前端安全应该如何设计
FB-25-SE-A-017 前端供应链安全架构

参考资源：

口头回答版：

金融收银台安全要求很高。输入上要用安全键盘、敏感字段即时加密；防篡改上用 SRI、CSP、运行时校验；风控上要采集设备指纹和行为特征，异常时二次验证；支付渠道要做多路路由和自动切换，超时主动查询；日志要脱敏，符合 PCI-DSS。核心逻辑要下沉到服务端，前端只做展示和触发。

FB-25-SC-P-009：设计一个支持百万级数据的表格前端架构

题型：场景设计题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：大数据表格、虚拟滚动、分页、Canvas、性能、数据管道 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个能够流畅展示百万级数据的前端表格，说明数据获取、渲染、交互和性能优化策略。

参考答案：百万级表格不能一次性渲染 DOM，需要数据管道 + 虚拟渲染 + 按需加载。

架构：

text

数据源 → 服务端分页/流式 → 前端数据管道 → 虚拟滚动渲染 → 视图层

核心策略：

数据层
- 服务端分页：每次只请求当前页数据。
- 服务端排序/筛选：避免前端处理全量数据。
- 游标分页：大数据集避免深度分页 offset 性能问题。
- 数据快照/索引：服务端提供筛选索引，加速命中。
渲染层
- 虚拟滚动：只渲染可视区域行，回收 DOM。
- 虚拟列：列数很多时同样只渲染可视列。
- Canvas / WebGL：超大数据量时用 canvas 表格（如 ag-grid enterprise）。
- 行高估算：动态行高需要估算并修正滚动条位置。
交互层
- 选中、展开、编辑使用行级状态，不触发全量重渲染。
- 批量操作先记录 ID，再提交服务端。
- 搜索建议用 debounce，避免每次输入都请求。
性能优化
- 对象池复用 DOM 节点。
- requestAnimationFrame 分批处理非关键更新。
- Web Worker 处理排序、聚合等计算。
- 分页缓存，减少重复请求。

最佳实践：

明确业务是否需要真正的"百万行同时可见"，多数场景只需服务端分页。
提供导出、聚合视图等替代方案，避免用户直接看海量明细。
对关键操作做性能基线测试，锁定渲染帧率。

评分维度：

数据策略（30%）：是否用服务端分页、游标、筛选索引
渲染优化（30%）：是否提到虚拟滚动、虚拟列、Canvas
交互设计（20%）：是否考虑选中、编辑、批量操作的性能
工程保障（20%）：是否提到缓存、Worker、性能基线

常见错误：

把百万行数据全量拿到前端再分页。
虚拟滚动实现不当导致滚动条跳变。
前端做全量排序筛选，造成主线程卡顿。

延伸追问：

如果候选人答对了，可追问：用户要求表格支持任意列排序，你会把排序放前端还是后端？
如果候选人答错了，可引导：一次性渲染一万行 DOM 会发生什么？

相关题目：

FB-25-PE-A-016 首屏加载架构优化
FB-25-CP-A-005 如何评估一个前端架构的可扩展性

参考资源：

口头回答版：

百万级表格不能一次渲染 DOM。数据上用服务端分页、游标和索引，避免前端处理全量；渲染上用虚拟滚动只渲染可视区，列多再用虚拟列，极端情况用 Canvas。交互上选中、编辑用行级状态，批量操作记录 ID。还要缓存、Web Worker、性能基线。多数业务其实不需要真的同时看百万行，分页就够了。

FB-25-SC-P-010：设计一个前端国际化架构

题型：场景设计题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：国际化、i18n、RTL、本地化、多语言、翻译管理 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请设计一个前端国际化架构，支持多语言、复数、日期货币、RTL 布局，并说明翻译管理、动态加载和发布流程。

参考答案：前端国际化不仅是文本翻译，还包括格式、布局、文化和运行时切换。

架构分层：

text

┌─────────────────────────────┐
│  UI 层：RTL、镜像、图标语义    │
├─────────────────────────────┤
│  翻译层：key-value、插值、复数 │
├─────────────────────────────┤
│  格式化层：时间、数字、货币    │
├─────────────────────────────┤
│  加载层：按路由/组件懒加载    │
├─────────────────────────────┤
│  管理平台：翻译 TMS、版本控制  │
└─────────────────────────────┘

核心设计：

翻译管理
- 使用 ICU MessageFormat 支持插值、复数、选择。
- 翻译 key 采用结构化命名，如 order.confirmButton。
- TMS（如 Crowdin、Phrase）与代码仓库双向同步。
运行时加载
- 默认语言打包，其他语言按路由或用户切换时异步加载。
- 语言包做 JSON 拆分，避免单文件过大。
格式化
- 日期、时间、数字、货币使用 Intl API 或 FormatJS。
- 时区、历法差异由服务端或配置决定。
RTL 与布局
- 使用逻辑属性（margin-inline-start）和 CSS 变量。
- 对 RTL 语言做镜像布局和图标翻转。
- 测试覆盖 RTL 渲染。
发布流程
- 翻译变更走 TMS → PR → CI 校验 → 发布。
- 关键文案灰度，避免翻译错误上线。

最佳实践：

不要把句子拆成多个 key 拼接，避免语序问题。
图片、图标避免包含文字。
提供语言回退机制，缺失翻译显示默认语言。

评分维度：

翻译管理（30%）：是否使用 MessageFormat、TMS、结构化 key
运行时加载（25%）：是否按语言异步加载和回退
格式与 RTL（25%）：是否覆盖日期货币、RTL、逻辑属性
发布流程（20%）：是否说明翻译变更的 CI/CD 流程

常见错误：

把中文句子拆成多段 key，导致其他语言语序混乱。
所有语言打包在一个 bundle 里，体积巨大。
只做了文本替换，忽略 RTL 和日期格式。

延伸追问：

如果候选人答对了，可追问：阿拉伯语和英语混排时，RTL 怎么处理？
如果候选人答错了，可引导：复数形式在不同语言里规则不同，怎么支持？

相关题目：

FB-25-SD-R-008 设计一个全球化多端统一前端架构
FB-25-SC-A-011 如何设计一个支持多租户的前端应用

参考资源：

口头回答版：

前端国际化不只是翻译文本，还要处理日期、数字、货币、RTL 布局和语言包加载。翻译用 ICU MessageFormat 支持复数和插值，key 结构化命名，和 TMS 平台同步。默认语言打包，其他语言异步加载。布局用 CSS 逻辑属性支持 RTL，图标注意镜像。发布时翻译变更走 CI 校验和灰度。

FB-25-SC-P-011：设计一个前端权限架构（RBAC/ABAC）

题型：场景设计题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：权限架构、RBAC、ABAC、ACL、权限模型、路由守卫 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个前端权限架构，支持 RBAC 和 ABAC 模型，覆盖菜单、路由、按钮、数据字段等粒度，并说明权限数据的获取与缓存策略。

参考答案：前端权限架构需要与后端配合，做到"服务端校验为主、前端控制为辅"。

权限模型：

模型	说明	适用
ACL	直接给用户绑定资源权限	简单系统
RBAC	用户 → 角色 → 权限	角色稳定的组织
ABAC	基于属性动态判断	复杂业务规则

架构设计：

text

用户登录 → 获取权限数据 → 权限中心 → 路由/菜单/按钮/字段控制

权限数据获取
- 登录后一次性拉取用户权限码列表或角色。
- 大权限体系可按路由/模块懒加载。
- 服务端同时返回数据权限规则（如只能看本部门）。
权限中心
- 封装 hasPermission(code)、hasRole(role)、hasDataScope(scope)。
- 支持函数式与指令式两种用法。
菜单与路由
- 路由元信息绑定权限码。
- 无权限路由重定向到 403 或隐藏。
- 动态生成侧边栏菜单。
按钮与字段
- 使用 <Permission code="order:edit"> 组件包裹按钮。
- 表格列根据权限动态显示/隐藏。
数据权限
- 前端仅做展示控制，真正的数据过滤由服务端完成。
- 对敏感字段做脱敏展示。

最佳实践：

权限数据缓存于内存，退出登录时清空。
权限变更后需要刷新或重新登录。
前端权限不可信，关键操作必须服务端二次校验。

评分维度：

模型理解（25%）：能否解释 RBAC、ABAC、ACL 的差异
粒度覆盖（25%）：是否覆盖菜单、路由、按钮、字段、数据权限
架构设计（25%）：是否提到权限中心、动态路由、指令组件
安全与缓存（25%）：是否强调服务端校验、缓存、脱敏

常见错误：

只控制菜单隐藏，不控制路由访问。
前端权限判断绕过即可操作后端，没有服务端校验。
把权限码硬编码在业务组件里，难以维护。

延伸追问：

如果候选人答对了，可追问：用户权限在会话中发生变化，前端如何感知？
如果候选人答错了，可引导：菜单隐藏了但直接输入 URL 还能访问，说明什么问题？

相关题目：

FB-25-SC-A-001 大型中后台系统如何进行模块拆分和分层
FB-25-SD-P-008 设计一个金融级前端安全收银台

参考资源：

口头回答版：

前端权限架构一般采用 RBAC 或 ABAC。登录后拉取权限码或角色，封装一个权限中心提供 hasPermission 这类方法。然后控制菜单、路由、按钮和字段显隐。数据权限主要还是靠服务端过滤，前端只做展示控制。关键操作服务端要二次校验，不能只信前端。

FB-25-CO-P-012：什么是数据一致性？前端如何保证最终一致性？

题型：概念题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：数据一致性、最终一致性、乐观更新、冲突解决、同步 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释数据一致性的概念，说明前端在弱网、离线、多端场景下如何保证最终一致性，并举例说明。

参考答案：数据一致性指多个副本或多方对同一数据的视图保持一致。前端场景下常讨论强一致性、最终一致性和离线一致性。

前端保证最终一致性的策略：

乐观更新
- 用户操作后立即更新本地 UI，同时异步提交服务端。
- 失败时回滚或提示用户重试。
本地队列与重试
- 弱网时把操作放入本地队列，网络恢复后按顺序重试。
- 操作幂等：每个操作带唯一 ID，防止重复提交。
版本向量 / 时间戳
- 每条数据带版本号或更新时间，合并时以最新为准（LWW）。
- 冲突时提示用户选择或自定义合并策略。
状态同步协议
- 使用 SWR / TanStack Query 的 stale-while-revalidate 策略。
- WebSocket 推送服务端状态变更，客户端合并。
离线优先
- 本地维护一份完整数据副本，离线时读写本地，同步后合并。
- CRDT 或本地数据库（IndexedDB）实现无冲突合并。

示例：购物车加减商品

text

用户点击 +1 → 本地购物车立即 +1 → 发请求 → 成功后刷新服务端版本
请求失败 → 提示用户并回滚本地状态

最佳实践：

区分"本地状态"和"服务端状态"，避免混用。
关键操作失败后必须明确告知用户。
同步冲突时优先保护用户数据，提供恢复路径。

评分维度：

概念理解（30%）：能否解释一致性类型和最终一致性
策略覆盖（40%）：是否提到乐观更新、队列重试、版本号、离线优先
前端实践（20%）：能否结合 SWR、WebSocket、CRDT 举例
容错意识（10%）：是否提到失败回滚、用户提示、幂等

常见错误：

乐观更新失败后静默回滚，用户感知不到。
没有幂等机制，弱网重试导致重复数据。
把前端本地状态直接当权威数据源。

延伸追问：

如果候选人答对了，可追问：两个设备同时修改同一份离线数据，怎么合并？
如果候选人答错了，可引导：用户点了赞，网络断了，刷新页面后发现赞没了，怎么办？

相关题目：

FB-25-CO-B-014 集中式状态管理与局部状态管理
FB-25-SD-A-012 设计一个前端实时协同编辑系统

参考资源：

口头回答版：

数据一致性就是多方看到的数据要一致。前端常用乐观更新，先改 UI 再发请求，失败回滚；弱网时把操作放队列里重试，每个操作带唯一 ID 保证幂等；数据带版本号，合并时以新的为准；离线场景用本地数据库或 CRDT 实现无冲突合并。关键操作失败要提示用户。

FB-25-CO-P-013：什么是无服务器/边缘渲染架构？前端如何落地？

题型：概念题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：Serverless、边缘渲染、Edge、Vercel、SSR、CDN 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释无服务器（Serverless）和边缘渲染（Edge Rendering）的概念，说明它们对前端架构的影响以及落地方式。

参考答案： Serverless 指开发者无需管理服务器，按请求运行代码；边缘渲染是把渲染逻辑部署到离用户最近的 CDN 边缘节点，降低延迟。

对前端架构的影响：

渲染位置前移：从中心服务器下放到边缘节点，提升 TTFB。
动态与静态融合：边缘节点可以基于请求参数生成个性化页面。
运维简化：无需关心扩缩容，按调用计费。
安全与隔离：函数运行环境受限，需要注意冷启动和状态管理。

落地方式：

方案	说明	代表平台
SSR on Serverless	Next.js / Nuxt 部署到 Vercel、Netlify Functions	Vercel
边缘渲染	在 Cloudflare Workers、Vercel Edge 运行渲染逻辑	Cloudflare、Vercel Edge
边缘缓存 + 部分渲染	静态壳 + 边缘注入动态数据	自定义 Worker

架构示例：

text

用户请求 → CDN 边缘节点 → Edge Function 渲染 HTML → 缓存 → 浏览器
                ↓
            中心 API（动态数据）

最佳实践：

把不变部分尽量缓存，动态部分通过边缘函数获取。
注意边缘运行时的限制：CPU、内存、执行时长。
敏感数据不要在边缘长时间缓存。
提供降级到中心 SSR 或 CSR 的能力。

评分维度：

概念理解（35%）：能否区分 Serverless 和边缘渲染
架构影响（25%）：是否提到 TTFB、动态静态融合、运维简化
落地方式（25%）：能否说出具体平台和部署模式
注意事项（15%）：是否考虑冷启动、缓存、降级、安全

常见错误：

认为边缘渲染适合所有场景，忽视动态数据实时性。
把需要长连接或状态保持的逻辑放到 Serverless。
忽略边缘运行时的环境限制。

延伸追问：

如果候选人答对了，可追问：边缘渲染和 CDN 静态缓存的最大区别是什么？
如果候选人答错了，可引导：为什么边缘渲染能降低首屏时间？

相关题目：

FB-25-PE-A-016 首屏加载架构优化
FB-25-SD-A-002 设计一个支持多终端接入的 BFF 层

参考资源：

口头回答版：

Serverless 是不用管服务器，按请求跑代码；边缘渲染是把渲染逻辑放到 CDN 边缘节点，离用户更近，TTFB 更低。前端可以把 Next.js、Nuxt 部署到 Vercel 或 Cloudflare Workers 上。落地时要注意把静态部分缓存，动态部分边缘获取，注意运行时长和内存限制，还要有降级方案。

FB-25-CP-P-014：如何做技术债管理与架构演进路线图？

题型：综合开放题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：技术债、架构演进、路线图、重构、治理 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请描述如何在团队中管理技术债，并制定可落地的架构演进路线图。

参考答案：技术债管理不是一次性清理，而是持续识别、分类、度量和偿还的过程。

管理流程：

识别与记录
- 代码审查、架构评审、生产故障复盘中发现技术债。
- 建立技术债登记表，记录位置、影响、原因、预计偿还成本。
分类与优先级
- 按影响：高风险（阻塞发布）、中风险（拖慢开发）、低风险（可接受）。
- 按类型：设计债、代码债、测试债、基础设施债、文档债。
度量
- 代码复杂度、测试覆盖率、构建时间、循环依赖数、故障率。
- 用趋势图展示技术债增长或下降。
偿还策略
- boy scout rule：改动代码时顺手清理周边。
- 专项重构：在每个迭代中预留 10%-20% 技术债时间。
- 绞杀者模式：新功能用新架构，逐步替换旧模块。
架构演进路线图
- 明确当前状态、目标状态和中间里程碑。
- 按季度规划可验证的产出，如"Q2 完成订单域模块化拆分"。
- 路线图与业务目标对齐，避免纯技术项目。

最佳实践：

技术债要可见，定期向管理层汇报。
不追求零技术债，而是控制增长曲线。
关键债必须写 ADR 记录决策和偿还计划。

评分维度：

管理流程（35%）：是否覆盖识别、分类、度量、偿还
路线图制定（30%）：是否有里程碑、目标状态、与业务对齐
落地能力（20%）：是否提到 boy scout rule、专项时间、绞杀者模式
沟通意识（15%）：是否提到登记、汇报、ADR

常见错误：

把技术债当成一个项目，期望一次还清。
只记录不行动，技术债表变成摆设。
没有度量指标，无法证明改进效果。

延伸追问：

如果候选人答对了，可追问：业务方不给你重构时间，你会怎么争取？
如果候选人答错了，可引导：技术债和 bug 有什么区别？

相关题目：

FB-25-CP-A-015 如何处理遗留系统的渐进式重构
FB-25-CO-B-006 什么是 ADR

参考资源：

口头回答版：

技术债管理要先识别和记录，按影响和类型分类，再用复杂度、测试覆盖率、构建时间等指标度量。偿还可以顺手清理、迭代里预留时间、或者用绞杀者模式逐步替换。架构演进路线图要明确当前和目标状态，按季度设里程碑，和业务目标对齐，关键债要写 ADR。

FB-25-EN-P-015：Monorepo 中的构建性能优化与远程缓存架构

题型：工程化题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：Monorepo、远程缓存、构建性能、Turborepo、Nx、任务编排 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请说明 Monorepo 下构建性能瓶颈的来源，并设计一套远程缓存和任务编排方案。

参考答案： Monorepo 构建瓶颈主要来自任务重复执行、依赖图复杂、缓存未命中和串行构建。

瓶颈来源：

任务数量多：几十个包同时构建、测试、lint。
重复计算：不同分支或 CI 经常执行相同任务。
依赖阻塞：任务间依赖关系导致串行等待。
I/O 大：安装依赖、写产物、跑测试产生大量磁盘操作。

优化方案：

任务编排
- 使用 Turborepo / Nx 分析依赖图，并行执行无依赖任务。
- 定义任务 pipeline，如 build 依赖 ^build，test 依赖 build。
本地缓存
- 基于输入 hash 缓存任务输出，命中时直接复用。
- 缓存位置通常在 node_modules/.cache。
远程缓存
- 团队共享缓存服务器，CI 和本地都能命中。
- 常用方案：Vercel Remote Cache、Nx Cloud、自研 S3/NFS 缓存。
分布式任务执行
- Nx Cloud 的 DTE 将任务分发到多台 agent 并行执行。
- 适合大型 Monorepo 的 CI 场景。
精细化输入
- 准确声明 task inputs，避免无关文件变动导致缓存失效。
- 把产物输出到统一目录，便于缓存。

架构：

text

开发者本地/CI → Turborepo/Nx → 本地缓存 / 远程缓存 → 缓存存储（S3/Redis）
                    ↓
              分布式 Agent 集群

最佳实践：

远程缓存需要权限控制，防止污染。
缓存失效时要有降级构建能力。
定期清理过期缓存，控制存储成本。

评分维度：

瓶颈识别（25%）：能否指出任务多、重复、依赖阻塞、I/O 等瓶颈
任务编排（25%）：是否提到依赖图并行、pipeline 定义
缓存设计（30%）：是否覆盖本地缓存、远程缓存、输入 hash、权限
分布式与成本（20%）：是否提到 DTE、缓存清理、降级

常见错误：

所有任务都串行执行，不利用并行能力。
缓存输入声明过宽，导致缓存频繁失效。
远程缓存没有权限控制，任何人都能污染。

延伸追问：

如果候选人答对了，可追问：本地缓存命中但远程缓存没命中，可能是什么原因？
如果候选人答错了，可引导：Monorepo 里改动一个文件，为什么要重新构建所有包？

相关题目：

FB-25-EN-A-004 Monorepo 中如何设计包依赖和版本策略
FB-25-EN-B-003 Monorepo 是什么

参考资源：

口头回答版：

Monorepo 构建慢主要是因为任务多、重复计算、依赖阻塞。优化要用 Turborepo 或 Nx 做任务编排，把没有依赖的任务并行跑；再用输入 hash 做本地和远程缓存，CI 和本地共享缓存；大型仓库还可以用分布式任务执行。要精细声明缓存输入，防止无关文件变动导致失效，远程缓存要有权限控制。

FB-25-SS-P-016：如何设计并落地前端技术委员会机制？

题型：软技能题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：25 系统架构设计标签：技术委员会、技术治理、决策机制、RFC、技术选型 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端技术委员会的定位、职责和运作机制，以及如何保证其在组织中的有效性。

参考答案：前端技术委员会是跨团队的技术决策和治理组织，负责统一方向、沉淀标准、推动演进。

定位：

不是行政权力机构，而是技术共识形成机制。
连接一线开发和架构目标，避免各业务线各自为政。

职责：

技术选型与标准：框架、工具链、代码规范、安全基线。
架构评审：重大改造、跨域项目、新建基础设施。
技术债治理：制定偿还计划，监控技术健康度。
知识沉淀：RFC、ADR、技术分享、最佳实践。
人才培养：技术晋升、导师计划、跨团队轮岗。

运作机制：

定期会议：双周或月度，议题提前征集。
RFC 流程：重大变更先写 RFC，公开评审后决策。
决策方式：主要负责人拍板、多数表决或共识制，需明确。
执行跟踪：决议形成任务，指定负责人和 deadline。
复盘机制：季度回顾决策效果，及时调整。

有效性保障：

成员要有代表性，覆盖各业务线和层级。
议题要接地气，解决实际问题，避免空泛。
决策要透明，结论和理由公开可查。
对不执行的决议要有反馈和问责。

最佳实践：

会前充分异步沟通，会上聚焦决策。
引入外部专家参与关键评审。
把委员会产出与绩效、晋升挂钩，提升影响力。

评分维度：

定位与职责（35%）：是否清楚说明委员会不是行政机构及五大职责
运作机制（35%）：是否提到会议、RFC、决策、跟踪、复盘
有效性保障（20%）：是否考虑代表性、透明度、问责
落地意识（10%）：是否提到会前异步、外部专家、绩效挂钩

常见错误：

把技术委员会开成务虚会，没有实际产出。
决策没有执行跟踪，变成议而不决。
成员全部来自一个团队，失去代表性。

延伸追问：

如果候选人答对了，可追问：委员会和业务线技术负责人在选型上意见冲突怎么办？
如果候选人答错了，可引导：技术委员会和普通的周会有什么区别？

相关题目：

FB-25-CP-P-004 如何做一次技术选型决策并沉淀 ADR
FB-25-SS-R-005 如何推动一个重大技术架构升级在多个业务线落地

参考资源：

口头回答版：

前端技术委员会是跨团队的技术决策组织，负责选型、标准、架构评审、技术债治理和知识沉淀。运作上要有定期会议、RFC 流程、明确的决策方式和执行跟踪。要保证有效性，成员要有代表性，议题要接地气，决策要透明，决议要有问责。

架构题（71 道）

FB-25-SD-R-001：设计一个组织级前端架构治理体系

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计、44 技术治理标签：架构治理、组织级、标准、度量、架构师 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个组织级前端架构治理体系，目标是在多个业务线、多个团队之间保持技术一致性、控制架构腐化、提升交付效率。要求覆盖治理范围、标准体系、度量指标、落地机制。

参考答案：

治理范围
- 技术栈：框架、构建工具、核心库版本。
- 工程规范：代码风格、目录结构、API 设计、安全规范。
- 架构原则：分层、依赖方向、模块化边界。
- 公共能力：组件库、工具库、BFF、埋点、监控。
- 流程：技术选型、架构评审、升级迁移、技术债管理。
治理分层

text

┌─────────────────────────────────────┐
│  战略层：技术愿景 / 技术雷达 / 年度规划    │
├─────────────────────────────────────┤
│  标准层：技术规范 / ADR / 脚手架 / 模板   │
├─────────────────────────────────────┤
│  平台层：组件库 / CI/CD / 监控 / 低代码   │
├─────────────────────────────────────┤
│  执行层：Code Review / 架构评审 / 审计    │
├─────────────────────────────────────┤
│  反馈层：度量指标 / 技术债看板 / 复盘     │
└─────────────────────────────────────┘

标准体系
- Mandatory（强制）：安全规范、核心依赖版本、编码红线。
- Recommended（推荐）：目录结构、测试策略、性能预算。
- Optional（可选）：特定业务线的技术选择。
- 通过 ESLint/Stylelint/Arch 检测把规范落到 CI。
公共能力平台
- 统一脚手架：内置规范、模板、发布流程。
- 组件库/设计系统：跨业务复用。
- 构建与发布平台：统一 CI/CD、制品管理。
- 可观测平台：错误监控、性能监控、埋点。
度量指标
- 质量：代码覆盖率、Sonar 问题数、循环依赖数、重复代码率。
- 效率：构建时间、发布频率、需求交付周期。
- 架构健康：模块耦合度、公共库复用率、技术债数量。
- 安全：漏洞修复时长、依赖审计问题数。
落地机制
- 架构委员会：跨团队技术决策和评审。
- 架构守护：CI 中运行架构检测，禁止违规依赖。
- 技术债管理：登记、分级、排期偿还。
- 培训与分享：技术大会、内部分享、文档沉淀。
- 激励与问责：把架构健康纳入团队 OKR。
平衡一致性与灵活性
- 核心层强制统一，业务层允许差异化。
- 引入“例外申请”机制，特殊场景可审批偏离。

最佳实践：

治理不是管控，而是提供能力和降低摩擦。
先建公共能力，再推规范，最后做度量。
治理体系本身也要演进，定期复盘标准是否仍然适用。

评分维度：

治理范围（25%）：是否覆盖技术栈、规范、公共能力、流程
体系完整性（25%）：是否分层设计，包含战略、标准、平台、执行、反馈
度量能力（20%）：是否提出可量化的指标
落地机制（20%）：是否说明架构委员会、守护、技术债管理等机制
平衡思维（10%）：是否考虑一致性与灵活性的平衡

常见错误：

把治理做成纯粹管控，导致业务团队抵触。
只定规范不做工具和平台，执行不下去。
指标过多或不相关，团队疲于应付。

延伸追问：

如果候选人答对了，可追问：如果业务团队抱怨规范太多影响效率，你会怎么调整？
如果候选人答错了，可引导：架构治理和“技术管控”有什么区别？

相关题目：

FB-25-CO-R-004 架构评审应该关注哪些方面
FB-25-CP-R-002 如何平衡前端技术栈的统一与差异化

参考资源：

口头回答版：

组织级前端治理我会分五层：战略层定技术愿景和年度规划；标准层出规范、ADR、脚手架；平台层做组件库、CI/CD、监控；执行层做 Code Review 和架构评审；反馈层做度量指标和技术债看板。治理范围覆盖技术栈、工程规范、架构原则、公共能力、流程。度量上关注代码质量、构建效率、架构健康、安全漏洞。落地靠架构委员会、架构守护 CI、技术债管理、培训分享。关键是治理不是管控，要给业务团队降摩擦，核心强制、业务灵活。

FB-25-CP-R-002：如何在大型组织中平衡前端技术栈的统一与团队的差异化需求？

题型：综合开放题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计、39 技术战略标签：技术栈、统一与差异、组织、架构权衡 出现频率：中频 预计回答时长：10-15 分钟

题目描述：在大型组织中，既有统一技术栈带来的协同收益，也有不同业务团队对差异化技术栈的合理需求。请说明你会如何平衡这两者。

参考答案：

平衡策略：分层统一、边界清晰、例外机制。

定义统一层级

层级	统一程度	说明
基础设施	强制统一	Node 版本、包管理器、CI/CD 平台、监控
框架与核心库	推荐统一	React/Vue 主版本、状态管理、路由、构建工具
公共能力	推荐复用	组件库、工具库、BFF 规范、埋点 SDK
业务实现	允许差异	业务组件、页面逻辑、特定第三方库
创新实验	例外申请	新技术试点，验证后再决定是否推广

统一的价值
- 降低人员流动成本。
- 公共库一次建设多处复用。
- 减少重复造轮子。
- 安全漏洞和升级成本可控。
差异化的合理场景
- 特定端要求：小程序、桌面端、可视化场景需要不同技术栈。
- 性能要求：某些场景需要 WebAssembly、Canvas、WebGL。
- 团队能力：某些团队在某项技术上有深度积累。
- 创新实验：验证新技术是否适合组织。
平衡机制
- 技术雷达：明确每个技术处于“采纳 / 试验 / 评估 / 暂缓”状态。
- 例外审批：差异需要写 ADR，经架构委员会审批。
- 公共能力抽象：把可复用部分下沉到共享包，允许上层差异化。
- 定期复盘：每年评估统一策略是否仍然合理。
避免一刀切
- 不要为了统一而统一，导致业务团队用不合适的工具做不合适的事。
- 统一是手段，提效和降低风险才是目的。

最佳实践：

用“默认推荐 + 例外申请”代替“强制所有”。
统一的最大公约数应该尽量小，只统一真正带来收益的部分。
差异化技术需要自行承担升级、安全、招聘等成本。

评分维度：

分层思维（35%）：能否按基础设施、框架、公共能力、业务实现分层讨论
价值识别（20%）：能否说明统一和差异各自的价值
机制设计（25%）：是否提出技术雷达、例外审批、复盘等机制
权衡能力（20%）：是否避免一刀切，体现架构权衡

常见错误：

要求所有团队使用完全一样的技术栈。
为了创新允许无限差异化，导致技术债爆炸。
忽视统一带来的隐性收益（招聘、人员流动、升级成本）。

延伸追问：

如果候选人答对了，可追问：如果某个业务团队坚持要用 Svelte 而不是组织的 React，你会怎么处理？
如果候选人答错了，可引导：统一技术栈最大的成本是什么？

相关题目：

FB-25-SD-R-001 设计一个组织级前端架构治理体系
FB-25-CP-R-006 复杂系统架构中的权衡与取舍

参考资源：

口头回答版：

平衡统一和差异要分层。基础设施和 CI/CD 强制统一，框架和核心库推荐统一，公共能力推荐复用，业务实现允许差异，创新技术走例外申请。统一能降低人员流动成本、复用公共库、控制安全升级成本；差异适合特定端、性能要求、团队能力或创新实验。机制上可以用技术雷达定义技术状态，差异化要写 ADR 审批。关键是不要一刀切，统一是手段，最终要提效和控风险。

FB-25-SC-R-003：设计一个大型电商活动搭建平台的前端架构

题型：场景设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计、52 低代码 / 搭建标签：电商、活动搭建、低代码、高并发、配置化 出现频率：高频 预计回答时长：15-25 分钟

题目描述：请设计一个大型电商活动搭建平台的前端架构，支持运营同学通过可视化方式搭建大促活动页面，并能在 Web、App、小程序多端发布。要求覆盖搭建器、渲染、数据、性能、稳定性等核心方面。

参考答案：

整体架构

text

┌─────────────────────────────────────────────────┐
│                  运营搭建器（Builder）            │
│  模板市场 / 组件库 / 画布 / 数据绑定 / 预览 / 发布   │
└─────────────────────┬───────────────────────────┘
                      │  页面 Schema + 资源包
┌─────────────────────┴───────────────────────────┐
│                  页面配置服务                     │
│  版本管理 / 灰度 / AB 实验 / 审核 / CDN 分发        │
└─────────────────────┬───────────────────────────┘
                      │
        ┌─────────────┼─────────────┐
        │             │             │
┌───────┴───────┐ ┌───┴────┐ ┌──────┴──────┐
│   Web 渲染    │ │ App    │ │   小程序     │
│  (CSR/SSR/SSG)│ │ 渲染   │ │   渲染       │
└───────────────┘ └────────┘ └─────────────┘

搭建器设计
- 模板市场：预设行业模板，支持一键复制。
- 组件库：基础组件（图片、文本、按钮）、业务组件（商品、优惠券、倒计时、抽奖）。
- 画布：所见即所得，支持拖拽、层级、对齐、响应式预览。
- 数据绑定：支持 API、变量、表达式，配置数据映射。
- 预览与发布：多设备预览、版本管理、审核流。
Schema 与渲染
- 页面 Schema 描述组件树、样式、数据、事件、实验分组。
- 各端有独立渲染引擎，但都基于同一 Schema 协议。
- Web 端支持 SSR/SSG 用于 SEO 和大促首屏优化。
数据层设计
- 活动元数据：页面配置、组件配置、发布状态。
- 业务数据：商品、价格、库存、优惠券，通过 BFF 聚合。
- 实时数据：库存、倒计时、中奖结果通过 WebSocket 或长轮询。
- 缓存策略：静态配置 CDN 缓存，业务数据 Redis 缓存。
性能保障
- 资源优化：图片懒加载、WebP、CDN、资源预加载。
- 代码分割：按页面、按组件、按实验分组拆分。
- 大促压测：全链路压测，容量预估，自动降级。
- 边缘渲染：关键页面做 SSR 并缓存到 CDN 边缘节点。
稳定性保障
- 灰度发布：按用户、地域、流量百分比灰度。
- AB 实验：组件级实验，数据回流。
- 降级：配置解析失败用兜底模板，数据失败用占位。
- 监控：页面性能、错误率、业务转化率实时监控。
安全与合规
- 素材审核：图片、文案合规检测。
- 防止薅羊毛：抽奖/秒杀接口限流、防刷。
- 配置安全：Schema 校验、禁止动态脚本执行。

最佳实践：

把“页面配置”和“组件实现”解耦，运营改配置不触发发版。
大促前进行全链路演练和压测。
建立活动页面性能预算，超预算自动告警。

评分维度：

架构完整性（25%）：是否覆盖搭建器、配置服务、多端渲染、数据层
性能设计（20%）：是否考虑 SSR、CDN、代码分割、压测
稳定性（20%）：是否设计灰度、降级、监控、容灾
扩展性（15%）：是否支持组件扩展、模板市场、多实验
安全合规（10%）：是否提到审核、防刷、配置安全
业务理解（10%）：是否结合电商大促特点（秒杀、库存、转化）

常见错误：

只设计搭建器界面，忽略高并发和稳定性。
多端复用只做代码复用，不做渲染层解耦。
大促时才考虑性能，平时没有性能预算。

延伸追问：

如果候选人答对了，可追问：大促时某个组件接口被打挂了，如何做到只降级该组件不影响整个页面？
如果候选人答错了，可引导：电商活动和普通 CMS 页面最大的区别是什么？

相关题目：

FB-25-SD-P-001 设计一个低代码平台前端架构
FB-25-SC-P-002 设计一个 SDUI 系统

参考资源：

口头回答版：

电商活动平台分三层：运营搭建器、页面配置服务、多端渲染。搭建器要有模板市场、组件库、画布、数据绑定、预览发布；配置服务做版本、灰度、AB、审核、CDN 分发；渲染层有 Web、App、小程序各自引擎，但基于同一套 Schema。数据层通过 BFF 聚合商品、价格、库存，实时数据走 WebSocket。性能上要做 SSR/SSG、CDN、图片优化、代码分割、大促压测。稳定性靠灰度、降级、监控、全链路演练。还要注意防刷、素材审核、配置安全。

FB-25-CO-R-004：架构评审应该关注哪些方面？

题型：概念题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：架构评审、质量属性、风险、架构师 出现频率：高频 预计回答时长：5-8 分钟

题目描述：作为架构师，你在评审一个前端项目的技术方案时，会关注哪些方面？请列出评审清单并说明原因。

参考答案：

架构评审应关注以下方面：

业务目标对齐
- 方案是否解决真实业务问题？ROI 是否合理？
- 是否考虑了未来 6-12 个月的业务增长？
质量属性（Quality Attributes）
- 性能：首屏、运行时、构建性能是否满足预算？
- 可扩展性：新增功能是否需要大范围改动？
- 可维护性：代码结构、命名、文档是否清晰？
- 可测试性：是否容易写测试、mock 依赖？
- 可用性：降级、容错、监控是否完善？
- 安全性：XSS、CSRF、供应链、数据安全是否考虑？
依赖与耦合
- 模块边界是否清晰？是否存在循环依赖？
- 是否依赖不稳定或过时的库？
- 是否过度耦合某个框架或平台？
技术选型合理性
- 选型是否经过 PoC？是否有 ADR？
- 是否有备选方案？是否考虑“不换”的方案？
风险与回退
- 最大风险是什么？是否有回滚/回退方案？
- 上线后如何验证？是否有熔断降级？
团队协作与交付
- 方案是否超出团队能力范围？
- 是否需要跨团队协调？依赖方是否能按时交付？
- 文档、培训、迁移成本是否可接受？
成本与收益
- 开发成本、运维成本、学习成本。
- 预期收益是否可量化？

评审清单示例：

markdown

- [ ] 业务目标和成功指标清晰
- [ ] 质量属性（性能、可扩展、可维护、安全）已评估
- [ ] 依赖图无循环依赖
- [ ] 技术选型有 ADR 和 PoC
- [ ] 风险与回退方案已明确
- [ ] 团队有能力按时交付
- [ ] 上线后有监控和复盘计划

最佳实践：

评审不是挑刺，而是帮助团队识别盲点和风险。
评审结论要明确：通过、有条件通过、不通过。
对重大问题要跟踪闭环。

评分维度：

维度覆盖（35%）：是否覆盖业务、质量属性、依赖、选型、风险、协作、成本
评审方法（25%）：是否提出清单化、可追溯的评审方式
风险意识（20%）：是否强调风险和回退方案
协作意识（20%）：是否考虑团队能力和跨团队协作

常见错误：

只关注技术细节，忽略业务目标和 ROI。
评审流于形式，没有明确结论和跟踪。
用一套标准评所有项目，忽视项目规模差异。

延伸追问：

如果候选人答对了，可追问：评审时发现方案过度设计，但开发团队很想用新技术，你会怎么处理？
如果候选人答错了，可引导：架构评审和代码评审最大的区别是什么？

相关题目：

FB-25-SD-R-001 设计一个组织级前端架构治理体系
FB-25-CP-R-006 复杂系统架构中的权衡与取舍

参考资源：

口头回答版：

架构评审我会先看业务目标对不齐，成功指标清不清。然后看质量属性：性能、可扩展、可维护、可测试、可用、安全。接着看依赖和耦合，有没有循环依赖、有没有绑死某个框架。技术选型要有 ADR 和 PoC，有没有回退方案。还要看团队能不能按时交付、跨团队依赖多不多、成本收益是否合理。评审不是挑刺，要帮团队识别风险，结论要明确，问题要跟踪闭环。

FB-25-SS-R-005：如何推动一个重大技术架构升级在多个业务线落地？

题型：软技能题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计、40 沟通表达标签：架构升级、推动落地、变革管理、沟通 出现频率：中频 预计回答时长：8-12 分钟

题目描述：假设你负责推动公司将前端框架从 Vue 2 升级到 Vue 3，涉及 10 条业务线、上百个应用。请描述你的推动策略，包括沟通、节奏、风险处理和激励措施。

参考答案：

推动重大架构升级需要技术能力 + 变革管理能力。

建立共识
- 用数据和案例说明升级的必要性：维护成本、性能、招聘、安全风险。
- 明确愿景：升级后团队整体效率提升、技术债减少。
- 让业务线负责人参与目标制定，而不是被动接受。
试点验证
- 选择 1-2 个意愿强、影响小的业务线做试点。
- 输出迁移手册、自动化工具、常见问题 FAQ。
- 用试点数据证明收益：构建时间、bug 率、开发效率。
制定标准和工具
- 统一升级路径：代码扫描、自动迁移脚本、兼容层。
- 提供脚手架模板、Code Review 清单。
- 建立升级看板，跟踪各业务线进度。
分阶段推进
- 第一阶段：公共库、组件库升级。
- 第二阶段：新应用默认 Vue 3，旧应用渐进迁移。
- 第三阶段：核心应用集中攻坚。
- 第四阶段：收尾、下线 Vue 2。
沟通机制
- 周会同步进展和风险。
- 升级答疑群，快速响应问题。
- 定期发布战报，展示进展和收益。
风险处理
- 每个阶段设置回滚点。
- 关键应用升级前做充分回归测试。
- 保留双跑能力，出问题可快速切回。
激励与认可
- 把升级纳入团队 OKR 或技术债专项。
- 对完成迁移的团队给予公开认可和资源奖励。
- 收集并宣传成功案例。

最佳实践：

不要一次性推进所有团队，先让一部分人看到收益。
降低迁移成本比强制更重要：自动化工具、文档、支持。
理解业务压力，允许合理延期，但要保持整体节奏。

评分维度：

策略完整性（30%）：是否覆盖共识、试点、标准、分阶段、沟通、风险、激励
沟通能力（25%）：是否体现利益相关者管理和沟通机制
风险意识（20%）：是否设置回滚、双跑、测试保障
执行落地（15%）：是否提到工具、看板、自动化迁移
变革管理（10%）：是否考虑人性因素和激励

常见错误：

只发邮件通知，不做面对面沟通和答疑。
不考虑业务线压力，强制截止日期。
缺少试点，直接全量推进导致大面积故障。
升级后不做复盘和知识沉淀。

延伸追问：

如果候选人答对了，可追问：如果某个业务线负责人拒绝升级，你会怎么沟通？
如果候选人答错了，可引导：技术升级失败最常见的原因是什么？

相关题目：

FB-25-CP-P-004 如何做技术选型决策
FB-25-SD-R-001 设计一个组织级前端架构治理体系

参考资源：

口头回答版：

推动大升级要先建立共识，用数据说明为什么要升级，让业务线参与目标制定。然后选意愿强的业务线做试点，输出迁移手册和自动化工具。再制定统一标准和分阶段计划：先升公共库，再让新应用默认新框架，旧应用渐进迁移，最后攻坚核心应用。沟通上要周会同步、答疑群、发战报。风险上每个阶段设回滚点，关键应用充分测试，保留双跑能力。还要把升级纳入 OKR，对完成团队给认可和激励。关键是降低迁移成本，让大家看到好处。

FB-25-CP-R-006：在复杂系统架构设计中，如何做权衡与取舍？

题型：综合开放题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：架构权衡、取舍、成本、风险、架构思维 出现频率：高频 预计回答时长：8-12 分钟

题目描述：请结合一个你经历过的复杂系统架构设计案例，说明你是如何做权衡与取舍的。具体涉及哪些维度？最终决策的依据是什么？

参考答案：

复杂系统架构设计中没有完美方案，只有“在约束下最合适”的方案。权衡框架：

明确约束和目标
- 业务约束：交付时间、合规、预算。
- 技术约束：团队能力、现有系统、运维水平。
- 质量目标：性能、可用性、可扩展性、安全性。
列出候选方案
- 至少准备 3 个方案：激进、保守、折中。
- 包括“什么都不做”的方案。
评估维度

维度	关注点
短期收益	能否快速解决当前痛点
长期成本	维护、升级、迁移成本
风险	技术风险、业务风险、团队风险
可逆性	决策错了能否回退
一致性	是否符合组织整体技术方向
团队接受度	团队能否理解并执行

决策方法
- 加权评分表：给维度赋权，给方案打分。
- 最差情况分析：假设方案失败，损失是否可承受。
- 延迟决策：把不确定的决策推迟到信息更充分时。
记录与复盘
- 用 ADR 记录决策和权衡依据。
- 上线后复盘，验证假设是否成立。

示例：

某电商活动中台需要支持多租户页面搭建。候选方案：A. 自研低代码平台；B. 基于开源低代码引擎二次开发；C. 先用配置化方案满足 80% 需求。最终选 C，因为大促在即，自研周期长风险高；配置化方案 2 周上线，满足当前需求，同时保留后续迁移到完整低代码平台的能力。

最佳实践：

把复杂决策拆成多个可逆的小决策。
与利益相关者透明沟通取舍理由。
接受局部不完美，换取整体目标达成。

评分维度：

权衡框架（30%）：是否有系统的评估维度和方法
案例深度（25%）：是否结合真实或具体场景说明
多维度评估（25%）：是否从短期、长期、风险、可逆性等角度分析
决策透明（20%）：是否提到 ADR、沟通、复盘

常见错误：

只给出一个方案，没有比较和取舍。
忽视约束，追求技术最优。
决策后不记录，导致后续团队不理解。
用个人偏好代替客观评估。

延伸追问：

如果候选人答对了，可追问：如果事后发现决策错了，你会怎么调整？
如果候选人答错了，可引导：架构设计中“没有银弹”是什么意思？

相关题目：

FB-25-CP-P-004 如何做技术选型决策
FB-25-CO-R-004 架构评审应该关注哪些方面

参考资源：

口头回答版：

复杂系统做权衡，首先要明确业务和技术约束，以及质量目标。然后列出至少三个候选方案，包括什么都不做。评估维度看短期收益、长期成本、风险、可逆性、和组织方向是否一致、团队接受度。可以用加权评分表或最差情况分析。决策后要写 ADR，上线后复盘。比如大促前要选能快速上线、风险可控的方案，哪怕不是最完美的，但要保留未来演进空间。关键是接受局部不完美，换取整体目标。

FB-25-SD-R-007：设计一个跨团队共享的前端能力平台

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计、14 设计体系与组件库标签：能力平台、共享、设计体系、组件库、开发者体验 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个跨团队共享的前端能力平台，包含组件库、工具库、脚手架、文档、示例、贡献机制。要求说明如何促进业务团队使用、如何治理质量和版本、如何衡量平台价值。

参考答案：

平台定位与分层

text

┌─────────────────────────────────────┐
│  应用层：业务应用 / 活动页 / 小程序      │
├─────────────────────────────────────┤
│  解决方案层：业务模板 / 页面片段 / 最佳实践 │
├─────────────────────────────────────┤
│  组件层：基础组件 / 业务组件 / 图表      │
├─────────────────────────────────────┤
│  工具层：脚手架 / Hooks / Utils / SDK   │
├─────────────────────────────────────┤
│  基础设施层：设计规范 / 图标 / Token / 主题 │
└─────────────────────────────────────┘

核心能力模块
- 设计体系：Design Token、色彩、字体、间距、图标规范。
- 组件库：基础组件 + 业务组件，支持 Web、小程序多端。
- 工具库：Hooks、Utils、请求封装、埋点 SDK、权限 SDK。
- 脚手架：统一创建应用、组件、物料的模板和脚本。
- 文档与示例：Storybook/Dumi，含用法、最佳实践、迁移指南。
- 贡献机制：物料提交、Review、发布、激励流程。
促进使用
- 降低接入成本：一行命令初始化、完善文档、FAQ。
- 提供价值：组件经过设计、测试、性能优化，比业务自己写更好。
- 绑定工作流：脚手架集成到 CI，文档随代码一起发布。
- 技术支持：答疑群、 Office Hours、培训。
- 收集反馈：使用埋点、NPS 调研、定期用户访谈。
质量与版本治理
- 组件必须经过设计 Review、单元测试、视觉回归、性能基线。
- 使用 Semver，break change 走 migration guide。
- Monorepo 管理，独立版本发布。
- 废弃策略：旧版本标记 deprecated，给出迁移期限。
衡量平台价值
- 使用量：下载量、组件引用次数、覆盖业务线数。
- 效率：业务开发周期缩短、重复代码减少。
- 质量：线上组件相关 bug 数、视觉一致性提升。
- 满意度：业务团队 NPS、技术支持响应时效。
组织保障
- 设立平台团队或虚拟小组，明确维护者。
- 把平台贡献纳入绩效和晋升考量。
- 定期举办组件大赛、分享会，营造共建氛围。

最佳实践：

平台能力要“即插即用”，不要强迫业务团队改变工作流。
先解决一个高频痛点（如表格、表单），再扩展能力。
平台不是一次性项目，需要持续运营和迭代。

评分维度：

平台设计（30%）：是否覆盖组件、工具、脚手架、文档、贡献机制
推广策略（20%）：是否说明如何降低接入成本、提供支持
质量治理（20%）：是否有测试、版本、废弃策略
价值度量（15%）：是否提出可量化的指标
组织保障（15%）：是否考虑团队、激励、运营

常见错误：

只把组件库放上去，忽略脚手架、文档、示例。
平台团队闭门造车，不听取业务需求。
版本管理混乱，break change 频繁且无迁移指南。
不度量价值，无法证明平台存在的意义。

延伸追问：

如果候选人答对了，可追问：如果业务团队宁愿自己写组件也不用平台组件，你会怎么分析原因？
如果候选人答错了，可引导：能力平台和普通开源库最大的区别是什么？

相关题目：

FB-25-SD-R-001 设计一个组织级前端架构治理体系
FB-25-CP-R-002 如何平衡技术栈统一与差异化

参考资源：

口头回答版：

跨团队能力平台可以分五层：基础设施层放 Design Token 和规范；工具层放脚手架、Hooks、SDK；组件层放基础和业务组件；解决方案层放模板和最佳实践；最上面是业务应用。要促进使用，就要降低接入成本、文档完善、提供技术支持、绑定工作流。质量上组件要经过设计 Review、测试、视觉回归，版本用 Semver，break change 给迁移指南。价值通过使用量、效率提升、bug 减少、满意度来衡量。还要有专门的维护团队和贡献激励机制，平台不是做完就完，要持续运营。

FB-25-SD-R-008：设计一个全球化多端统一前端架构

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：全球化、多端统一、跨端、国际化、架构治理 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个面向全球用户的统一前端架构，同时服务 Web、App、小程序等多个端，支持多语言、多时区、多币种和本地化合规。

参考答案：全球化多端统一架构的核心是在"共享业务能力"和"端/区域差异化"之间找到平衡。

整体架构：

text

业务应用（Web/App/小程序）
        ↓
   跨端适配层（运行时/编译时）
        ↓
   共享能力层（组件、Hooks、SDK、BFF）
        ↓
   区域部署（CDN、边缘节点、合规网关）

设计要点：

共享能力层
- 设计体系、通用组件、业务组件、Hooks、请求 SDK 抽成跨端包。
- 使用 Monorepo 管理，统一版本和发布。
跨端适配层
- 编译时跨端：Taro、uni-app、React Native for Web 等。
- 运行时适配：抽象平台 API（存储、导航、支付、分享），各端实现。
国际化与本地化
- 语言包、RTL、日期/货币/地址格式统一处理。
- 区域配置中心管理不同国家的功能开关、支付方式、合规文案。
区域部署
- 静态资源按区域 CDN 部署，就近访问。
- 敏感数据遵守数据驻留要求，通过区域网关路由。
合规与安全
- GDPR、CCPA 等隐私合规：同意管理、数据删除、埋点脱敏。
- 不同国家的安全认证和支付方式适配。
治理与度量
- 跨端代码复用率、区域发布效率、本地化覆盖率。
- 统一埋点和监控，聚合全球用户数据。

最佳实践：

不要追求 100% 代码复用，接受端特有代码的存在。
区域差异通过配置和扩展点解决，而不是分支代码。
关键链路做区域降级和容灾。

评分维度：

架构分层（30%）：是否清晰划分应用、适配层、共享能力、区域部署
多端策略（25%）：是否说明编译时/运行时跨端和平台 API 抽象
全球适配（25%）：是否覆盖 i18n、合规、区域部署、数据驻留
治理意识（20%）：是否提到复用率、度量、降级、扩展点

常见错误：

为追求统一而牺牲各端体验。
用大量 if-else 处理区域差异。
忽略数据合规和隐私要求。

延伸追问：

如果候选人答对了，可追问：某个国家要求数据不能出境，前端架构要做什么调整？
如果候选人答错了，可引导：多端统一和简单响应式 Web 的最大区别是什么？

相关题目：

FB-25-SC-P-010 设计一个前端国际化架构
FB-25-SD-A-002 设计一个支持多终端接入的 BFF 层

参考资源：

口头回答版：

全球化多端统一架构要分成业务应用、跨端适配层、共享能力层和区域部署。共享层放组件、Hooks、SDK，用 Monorepo 管理；适配层用编译时或运行时方案抽象平台差异；本地化做 i18n、RTL、货币、合规；区域部署按 CDN 和数据驻留要求分布。不要追求百分百复用，区域差异走配置和扩展点。

FB-25-SD-R-009：设计一个前端智能化研发平台架构

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：智能化研发、AI 辅助、低代码、平台架构、Agent、效能 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个面向前端团队的智能化研发平台，集成 AI 辅助编码、自动化测试、智能审查和知识问答，说明平台模块、数据流和安全边界。

参考答案：前端智能化研发平台的目标是通过 AI 和自动化提升研发效率与质量，同时保证安全可控。

平台模块：

text

┌─────────────────────────────────────┐
│  应用入口：IDE 插件、Web 工作台、CLI   │
├─────────────────────────────────────┤
│  能力层：代码生成、重构、审查、测试、问答 │
├─────────────────────────────────────┤
│  编排层：任务规划、上下文管理、多 Agent 协作│
├─────────────────────────────────────┤
│  模型层：代码大模型、嵌入模型、微调模型    │
├─────────────────────────────────────┤
│  数据层：代码知识库、文档、最佳实践、反馈  │
└─────────────────────────────────────┘

核心能力：

AI 辅助编码
- IDE 插件提供代码补全、注释生成、函数实现、错误修复。
- 基于代码仓库上下文做 RAG，提升生成相关性。
智能审查
- MR/PR 时自动检查代码风格、安全、性能、架构违规。
- 生成审查意见和风险评分。
自动化测试
- 根据代码变更生成单元测试、E2E 用例。
- 智能回归选择，减少全量测试时间。
知识问答
- 基于代码库、文档、ADR 做 RAG 问答。
- 支持自然语言查询技术方案和历史决策。
Agent 工作流
- 复杂任务拆解为计划、执行、验证、反馈循环。
- 关键操作需人工确认，避免 AI 越权。

安全与边界：

代码不上传外部公有模型，优先私有化部署或安全网关。
敏感文件加入脱敏和黑名单。
AI 生成代码必须经过人工 review 和测试。

最佳实践：

从高频、低风险场景切入，如代码补全、注释生成。
收集用户反馈，持续微调模型和 prompt。
建立 AI 生成代码的归属和责任机制。

评分维度：

架构分层（30%）：是否清晰划分入口、能力、编排、模型、数据层
能力覆盖（25%）：是否覆盖编码、审查、测试、问答等核心能力
AI 工程化（25%）：是否提到 RAG、Agent、上下文管理、反馈
安全与治理（20%）：是否考虑私有化、脱敏、人工确认、责任机制

常见错误：

直接把代码发到外部公共模型，造成泄露风险。
期望 AI 一次性完成复杂开发，缺少人工 review。
忽略上下文管理，AI 生成代码与项目规范不符。

延伸追问：

如果候选人答对了，可追问：AI 生成的测试用例质量不高，怎么持续改进？
如果候选人答错了，可引导：智能化平台和普通代码生成工具的区别是什么？

相关题目：

FB-25-SD-P-001 设计一个低代码平台前端架构
FB-25-CP-R-013 如何评估与引入新兴技术

参考资源：

口头回答版：

前端智能化研发平台分入口层、能力层、编排层、模型层和数据层。能力包括 AI 辅助编码、智能审查、自动化测试和知识问答。通过 RAG 把仓库上下文喂给模型，用 Agent 拆解复杂任务，关键操作人工确认。安全上代码尽量不上传外部，敏感文件脱敏，AI 生成代码必须 review 和测试。

FB-25-SD-R-010：设计一个高可用的大促前端保障体系

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：大促、高可用、保障体系、容灾、降级、监控、压测 出现频率：高频 预计回答时长：15-20 分钟

题目描述：请设计一个支撑电商大促等高流量场景的前端保障体系，覆盖事前准备、事中监控、事后复盘，并说明降级和容灾策略。

参考答案：大促保障体系需要全链路、多层次的预防和应急能力。

保障体系：

text

事前：容量评估 → 压测 → 预案演练 → 静态化/降级准备
事中：实时监控 → 告警 → 自动/手动切换预案
事后：故障复盘 → 改进清单 → 知识沉淀

事前准备
- 容量评估：根据往年数据和预估流量评估 CDN、API、服务端容量。
- 性能基线：锁定核心页面 LCP、FCP、CLS、接口成功率。
- 压测：全链路压测、前端资源压测、降级演练。
- 静态化：商品详情、活动页预渲染为静态 HTML，减少动态请求。
- 预案整理：列出可能故障及对应降级开关、回滚方案。
事中监控
- 全链路监控：RUM、APM、业务指标、错误率、资源加载成功率。
- 大盘实时展示关键指标，异常自动告警。
- 值班机制 + 故障指挥官，确保快速响应。
降级与容灾
- 功能降级：关闭非核心功能（推荐、评论、互动）。
- 页面降级：静态兜底页、CDN 兜底。
- 接口降级：非关键接口返回缓存或空值。
- 异地多活：流量切换到其他区域或集群。
事后复盘
- 故障时间线、影响面、根因分析。
- 改进项明确负责人和完成时间。
- 更新预案和自动化脚本。

最佳实践：

大促前冻结非必要发布，减少变更风险。
所有降级开关必须经过演练验证，不能临阵磨枪。
核心链路要有明确的 SLA 和责任人。

评分维度：

体系完整性（30%）：是否覆盖事前、事中、事后三个阶段
容灾降级（25%）：是否设计功能、页面、接口、异地多活降级
监控告警（20%）：是否覆盖 RUM、APM、业务指标、值班机制
落地细节（15%）：是否有压测、预案演练、发布冻结
复盘意识（10%）：是否提到故障复盘和改进清单

常见错误：

只关注代码优化，不做容量评估和压测。
降级预案从未演练，真正故障时不敢用。
监控指标过多，关键告警被噪音淹没。

延伸追问：

如果候选人答对了，可追问：大促期间发现一个第三方 SDK 拖慢页面，你怎么处理？
如果候选人答错了，可引导：静态化页面和 CDN 缓存有什么不同？

相关题目：

FB-25-SD-R-008 设计一个全球化多端统一前端架构
FB-25-PE-A-016 首屏加载架构优化

参考资源：

口头回答版：

大促保障要分事前、事中、事后。事前做容量评估、压测、预案演练、静态化；事中实时监控、告警、按值班机制快速响应；事后复盘改进。降级包括功能降级、页面静态兜底、接口返回缓存、异地多活。大促前尽量冻结发布，所有降级开关都要演练过。

FB-25-SC-R-011：设计一个跨团队协作的组件共建与治理体系

题型：场景设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：组件共建、设计体系、治理、跨团队协作、贡献机制 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一套跨团队协作的组件共建与治理体系，使业务团队愿意贡献组件，同时保证组件库质量和一致性。

参考答案：组件共建治理体系需要兼顾"效率"和"质量"，通过机制降低贡献门槛，通过流程保证一致。

体系设计：

text

┌─────────────────────────────────────┐
│  贡献入口：物料平台、脚手架、文档模板   │
├─────────────────────────────────────┤
│  评审流程：设计 → 代码 → 测试 → 发布   │
├─────────────────────────────────────┤
│  质量标准：设计规范、API 规范、测试基线 │
├─────────────────────────────────────┤
│  运营机制：贡献激励、技术支持、数据度量 │
├─────────────────────────────────────┤
│  治理组织：组件委员会 + 核心维护者      │
└─────────────────────────────────────┘

降低贡献门槛
- 提供组件脚手架和模板，统一目录、测试、文档结构。
- 文档和示例清晰，包含用法、变体、最佳实践。
- 设立"组件导师"，帮助业务团队首次贡献。
评审与质量控制
- 设计评审：视觉、交互、可访问性、命名。
- 代码评审：架构、性能、API 一致性、安全性。
- 自动化测试：单元测试、视觉回归、 accessibility 检查。
- 发布前必须通过 CI 和指定维护者 approve。
标准与规范
- Design Token、API 命名、事件命名、版本策略统一。
- 组件分类：基础组件、业务组件、场景组件。
激励与运营
- 贡献排行榜、内部技术影响力、晋升加分。
- 定期举办组件大赛、最佳实践分享。
- 提供答疑群、Office Hours。
度量与治理
- 使用量、覆盖业务线、bug 率、重复造轮子比例。
- 组件委员会定期 review 低质量或废弃组件。

最佳实践：

组件库不是平台团队私有，业务团队要有 ownership。
对贡献者及时反馈，避免 PR 长期无人处理。
允许业务组件先沉淀再升级，不要一开始追求完美。

评分维度：

体系完整性（30%）：是否覆盖入口、评审、标准、运营、治理
质量保障（25%）：是否提到设计评审、测试、视觉回归、CI
激励机制（20%）：是否考虑降低门槛、激励、导师、反馈
度量与治理（15%）：是否有使用数据、委员会、废弃策略
可落地性（10%）：是否说明业务团队 ownership 和渐进升级

常见错误：

平台团队闭门造车，业务团队没有参与感。
贡献流程复杂，业务团队宁愿自己写。
只收组件不治理，仓库逐渐臃肿。

延伸追问：

如果候选人答对了，可追问：业务团队提交的组件质量不达标但需求紧急，你怎么处理？
如果候选人答错了，可引导：组件库和通用 UI 库最大的治理难点是什么？

相关题目：

FB-25-SD-R-007 设计一个跨团队共享的前端能力平台
FB-25-SS-P-016 如何设计并落地前端技术委员会机制

参考资源：

口头回答版：

跨团队组件共建要有低门槛的贡献入口、清晰的评审流程和统一标准。提供脚手架、模板和导师，评审覆盖设计、代码、测试、可访问性。用 Design Token 和 API 规范保持一致。激励上用排行榜、晋升加分、组件大赛。组件委员会定期 review 使用数据和组件质量，允许业务组件先沉淀再升级。

FB-25-CP-R-012：如何在业务快速迭代中保持架构质量？

题型：综合开放题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：业务迭代、架构质量、技术债、架构守护、质量门禁 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请描述在业务快速迭代、需求频繁变化的背景下，前端团队应采取哪些机制和策略来保持架构质量不滑坡。

参考答案：快速迭代中保持架构质量，需要把质量内建到流程中，而不是事后补救。

策略体系：

架构守护
- 用 dependency-cruiser、Nx、ESLint 固化依赖规则。
- CI 中跑架构测试，违规即阻塞合并。
质量门禁
- MR/PR 必须满足：测试通过、Lint 通过、代码覆盖率不下降、体积不暴涨。
- 引入 AI 代码审查辅助发现架构问题。
增量重构
- 每个迭代预留技术债时间，顺手清理（boy scout rule）。
- 新功能优先用新架构实现，旧模块用绞杀者模式替换。
设计评审
- 复杂需求先做轻量技术方案评审，避免拍脑袋写代码。
- 重大变更写 RFC 或 ADR。
可观测性
- 监控线上性能、错误、用户路径，及时发现架构退化。
- 定期进行架构健康度评估。
团队文化
- 把代码质量纳入绩效，鼓励重构和知识分享。
- 建立技术债登记和可视化机制。
业务沟通
- 用数据说明质量问题的成本，争取合理重构窗口。
- 把架构投入包装为交付效率提升，获得业务方支持。

最佳实践：

不要把"快"和"质量"对立，前期多一点设计能大幅减少后期返工。
定期做架构走查，识别热点模块。
允许小步快跑，但必须有安全网。

评分维度：

流程机制（35%）：是否覆盖守护、门禁、评审、重构、可观测性
技术策略（25%）：是否提到绞杀者、boy scout rule、架构测试
团队文化（20%）：是否考虑绩效、技术债登记、知识分享
业务平衡（20%）：是否能与业务方沟通争取重构时间

常见错误：

为了追求速度完全放弃代码质量。
只做功能测试，不做架构和依赖守护。
把重构和业务需求完全割裂，难以获得资源。

延伸追问：

如果候选人答对了，可追问：业务方说"先上线再说"，你怎么回应？
如果候选人答错了，可引导：快速迭代和架构质量一定是矛盾的吗？

相关题目：

FB-25-CP-A-015 如何处理遗留系统的渐进式重构
FB-25-CP-P-014 技术债管理与架构演进路线图

参考资源：

口头回答版：

业务快速迭代中保持架构质量，要靠流程内建：用 dependency-cruiser 等工具做架构守护，CI 设质量门禁，复杂需求先做设计评审，新功能用新架构、旧模块用绞杀者模式替换。还要监控线上健康度，定期评估架构，把代码质量纳入绩效。要学会用数据跟业务方沟通，争取重构窗口。

FB-25-CP-R-013：如何评估与引入新兴技术（如 AI 编码、WebAssembly）到生产？

题型：综合开放题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：技术评估、新兴技术、AI 编码、WebAssembly、PoC、风险 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请描述一个评估和引入新兴技术的完整流程，包括风险识别、试点验证、推广策略和退出机制。

参考答案：引入新兴技术需要在创新和控制风险之间取得平衡，不能"为了新而新"。

完整流程：

问题定义
- 明确当前痛点和业务目标，判断新技术是否是最佳解。
- 列出"不引入"的成本，避免为换而换。
技术调研
- 评估成熟度、社区活跃度、维护团队、许可证、学习曲线。
- 收集同行案例和失败教训。
风险识别
- 技术风险：不成熟、性能瓶颈、难以调试。
- 人员风险：团队学习成本、招聘难度。
- 安全风险：供应链、数据隐私、合规。
- 业务风险：交付延期、回滚成本。
PoC 试点
- 选择低风险、高频的场景做概念验证。
- 设定明确的成功指标：性能、效率、稳定性、团队满意度。
- 评估最坏情况下的回滚方案。
决策与 ADR
- 组织评审，对比候选方案，记录决策理由。
- 明确使用范围、禁止场景、维护责任人。
渐进推广
- 先在非核心模块落地，再扩展到核心链路。
- 建立内部培训、最佳实践文档、技术支持渠道。
持续评估与退出
- 定期 review 技术指标和业务价值。
- 若新技术未达预期，要有计划地迁移或退出。

最佳实践：

新兴技术引入必须有赞助人和维护团队。
不要在大促等关键时期大规模推广。
保持技术栈适度收敛，避免过度碎片化。

评分维度：

流程完整性（30%）：是否覆盖调研、风险、PoC、决策、推广、退出
风险识别（25%）：能否识别技术、人员、安全、业务风险
试点设计（25%）：是否设定成功指标、回滚方案、渐进推广
治理意识（20%）：是否提到 ADR、赞助人、维护团队、持续评估

常见错误：

只看技术热度，不看是否解决实际问题。
缺少 PoC 直接全量推广。
引入后没有维护团队，逐渐变成遗留负担。

延伸追问：

如果候选人答对了，可追问：AI 编码工具可能泄露代码，你如何在公司落地？
如果候选人答错了，可引导：新技术的"好"应该怎么量化？

相关题目：

FB-25-CO-B-005 技术选型的一般流程和关键维度
FB-25-SD-R-009 设计一个前端智能化研发平台架构

参考资源：

口头回答版：

引入新兴技术要先明确痛点，调研成熟度和风险，然后选低风险场景做 PoC，设好成功指标和回滚方案，再写 ADR 决策。推广要渐进，先在非核心模块用，建立培训和文档。最后要持续评估价值，不行就计划退出。关键是不要为了新而新，要有赞助人和维护团队。

FB-25-SS-R-014：如何推动组织级前端工程文化变革？

题型：软技能题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：工程文化、组织变革、DevOps、技术品牌、领导力 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请说明如何在大型组织内推动前端工程文化变革，包括目标设定、阻力克服、激励机制和效果度量。

参考答案：组织级工程文化变革是长期过程，需要自上而下支持与自下而上参与相结合。

变革路径：

明确愿景与目标
- 定义"我们想要什么样的工程文化"：质量优先、持续交付、数据驱动、开放协作。
- 把文化目标转化为可度量指标：发布频率、故障恢复时间、测试覆盖率、技术债增速。
找到早期支持者
- 从认同变革的团队先试点，积累成功案例。
- 用数据展示试点前后的效率、质量变化。
降低参与门槛
- 提供脚手架、模板、培训、文档和答疑支持。
- 让团队感受到变革带来的实际好处，而不是负担。
制度化保障
- 把工程实践纳入晋升、绩效、项目验收标准。
- 成立虚拟小组或技术委员会推动标准落地。
应对阻力
- 识别阻力来源：学习成本、担心影响交付、权力格局。
- 通过沟通、培训、共创方式化解，而非强制推行。
持续度量与宣传
- 定期发布工程健康度报告。
- 通过内部分享、技术品牌活动扩大影响力。

最佳实践：

文化变革不能靠一纸通知，必须嵌入日常工作流。
领导者要以身作则，公开支持并投入资源。
允许团队按自己的节奏渐进 adoption，不追求一步到位。

评分维度：

变革路径（35%）：是否覆盖愿景、试点、门槛、制度、阻力、度量
激励机制（25%）：是否提到晋升、绩效、案例宣传
阻力处理（20%）：是否能识别并化解组织阻力
可度量性（20%）：是否定义工程健康度指标

常见错误：

仅靠行政命令推行，忽视团队真实诉求。
没有度量指标，无法证明变革价值。
期望所有团队同时达到同样成熟度。

延伸追问：

如果候选人答对了，可追问：某个业务线始终不配合新规范，你会怎么处理？
如果候选人答错了，可引导：工程文化和单纯的工具链升级有什么区别？

相关题目：

FB-25-SS-R-005 如何推动一个重大技术架构升级在多个业务线落地
FB-25-SS-P-016 如何设计并落地前端技术委员会机制

参考资源：

口头回答版：

推动工程文化变革要先明确愿景和可度量目标，找认同的团队试点，降低参与门槛，用培训和工具支持。然后把工程实践纳入绩效和晋升，制度化保障。对阻力要沟通化解，不要强制。领导者要以身作则，持续度量并宣传成果，允许团队渐进 adoption。

FB-25-CO-R-015：架构师如何进行风险建模与失效模式分析？

题型：概念题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：风险建模、FMEA、失效模式、架构风险、韧性 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请说明架构师在系统设计阶段如何识别潜在风险、进行失效模式分析，并制定应对策略。

参考答案：风险建模与失效模式分析是架构师确保系统在异常情况下仍能运行的关键能力。

常用方法：

方法	关注点
FMEA（失效模式与影响分析）	列出组件失效方式、影响、发生概率、检测难度
威胁建模	从攻击者视角识别安全威胁
最坏情况分析	假设关键依赖全部不可用，系统如何表现
混沌工程	在生产或准生产环境注入故障验证韧性

分析步骤：

边界与资产识别：明确系统边界、关键路径、外部依赖。
失效模式枚举：网络超时、服务宕机、数据不一致、配置错误、流量激增等。
影响评估：对每个失效模式评估影响范围、严重程度和可检测性。
风险优先级：用 RPN（风险优先级数）= 严重度 × 发生度 × 检测度排序。
制定缓解措施：冗余、降级、熔断、限流、监控、自动化恢复。
验证与演练：通过压测、混沌工程、灾难恢复演练验证。

前端场景中的失效：

CDN 故障：切换备用 CDN 或启用本地缓存。
接口超时：设置超时、重试、熔断和兜底数据。
JS 异常：错误边界 + 降级页面。
第三方 SDK 不可用：延迟加载、异步检测、功能开关关闭。

最佳实践：

风险分析要尽早进行，并随架构演进更新。
把高风险缓解措施写进 ADR 和上线 checklist。
不要只分析单点故障，还要考虑级联失效。

评分维度：

方法掌握（30%）：能否说出 FMEA、威胁建模、混沌工程等方法
分析流程（30%）：是否覆盖识别、枚举、评估、排序、缓解、验证
前端场景（20%）：能否结合 CDN、接口、JS 异常等举例
落地意识（20%）：是否提到 ADR、checklist、级联失效

常见错误：

只关注功能正确性，忽视异常场景。
风险分析只停留在口头，没有文档和演练。
过度防御，为低概率风险引入极高复杂度。

延伸追问：

如果候选人答对了，可追问：如果核心接口 P99 延迟从 100ms 涨到 2s，前端架构上怎么应对？
如果候选人答错了，可引导：FMEA 中的 RPN 是怎么算的？

相关题目：

FB-25-SD-R-010 设计一个高可用的大促前端保障体系
FB-25-CP-R-006 在复杂系统架构设计中如何做权衡与取舍

参考资源：

口头回答版：

架构师做风险建模可以用 FMEA、威胁建模、最坏情况分析和混沌工程。先识别系统边界和关键路径，再枚举失效模式，评估影响和优先级，然后制定冗余、降级、熔断、限流这些缓解措施，最后通过压测和混沌工程验证。前端里要特别注意 CDN 故障、接口超时、JS 异常、第三方 SDK 不可用这些场景。

FB-25-CO-R-016：什么是演进式架构？如何设计可演进的系统？

题型：概念题难度：⚫ 架构 岗位层级：架构师 面试知识域：25 系统架构设计标签：演进式架构、可演进、增量、架构适应性、持续交付 出现频率：中频 预计回答时长：8-12 分钟

题目描述：请解释演进式架构的概念，说明它与一次性完美架构的区别，并给出设计可演进系统的方法。

参考答案：演进式架构（Evolutionary Architecture）强调架构应随业务和技术环境持续演进，而不是追求一次性设计完美。

与一次性完美架构的区别：

维度	演进式架构	一次性完美架构
目标	持续适应变化	预先覆盖所有需求
策略	小步迭代、可回滚	大规模 upfront design
度量	变更成本、反馈周期	是否符合初始设计
风险	早期不完美但可调整	后期难以改动

设计可演进系统的原则：

增量变更：把大改动拆分为可独立发布的小步骤。
可逆性：关键决策尽量可回滚，避免单行道。
适应度函数：用自动化测试、度量指标守护架构属性。
耦合与内聚：保持模块边界清晰，降低跨模块改动成本。
实验文化：通过 A/B 测试、功能开关验证假设。
技术债可见：持续偿还，防止架构腐化。

实践示例：

使用功能开关控制新模块上线比例。
通过防腐层隔离外部系统，便于替换。
用 Monorepo 和接口契约约束模块间依赖。
建立 CI/CD 和自动化测试，缩短反馈周期。

最佳实践：

不要为未来 5 年的需求过度设计。
把架构决策记录为 ADR，便于后续推翻或演进。
让架构评审成为持续活动，而非一次性事件。

评分维度：

概念理解（35%）：能否清楚解释演进式架构与一次性架构的区别
设计原则（35%）：是否提到增量、可逆性、适应度函数、耦合内聚
前端实践（20%）：能否结合功能开关、防腐层、Monorepo 举例
治理意识（10%）：是否提到 ADR、持续评审、技术债

常见错误：

把演进式当成不做设计、随意堆砌。
一开始就为不存在的需求引入复杂抽象。
没有适应度函数，架构退化无法及时发现。

延伸追问：

如果候选人答对了，可追问：如何判断当前系统是否还能继续演进？
如果候选人答错了，可引导：演进式架构是不是等于不需要 upfront design？

相关题目：

FB-25-CP-P-014 技术债管理与架构演进路线图
FB-25-CO-B-006 什么是 ADR

参考资源：

口头回答版：

演进式架构就是架构要随业务和技术环境持续演进，不是一次设计完美。关键原则是增量变更、可逆性、适应度函数、模块边界清晰、实验文化和可见的技术债。实践中用功能开关、防腐层、Monorepo、CI/CD 和自动化测试来支持演进。要定期评审架构，不要为未来不存在的需求过度设计。

FB-25-CO-A-014：什么是前端架构？它和框架有什么关系？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：5-8 分钟

题目描述：什么是前端架构？它和框架有什么关系。

参考答案：

前端架构是组织代码、管理复杂度、支持团队协作和系统演进的整体方案，包括分层设计、模块划分、状态管理、路由、构建部署、性能、质量等多方面。框架（如 Vue/React）是架构落地的工具，但会用框架不等于懂架构。架构是思想，框架是工具。

补充说明：

在实际落地前端架构它和框架有什么关系时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

能区分架构与框架（30%）
能列举架构涉及的关键维度（40%）
有实际项目经验或思考（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

前端架构是组织代码、管理复杂度、支持团队协作和系统演进的整体方案，包括分层设计、模块划分、状态管理、路由、构建部署、性能、质量等多方面。框架（如 Vue/React）是架构落地的工具，但会用框架不等于懂架构。架构是思想，框架是工具。

FB-25-CP-A-016：简述 MVC、MVVM、MVP 的区别，并举例前端中的应用。

题型：综合开放题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：5-8 分钟

题目描述：简述 MVC、MVVM、MVP 的区别，并举例前端中的应用。。

参考答案：

MVC：Model 负责数据，View 负责展示，Controller 接收输入并协调。前端代表：Backbone.js。
MVP：Presenter 作为 View 和 Model 的中介，View 很薄。前端应用较少，多见于需要强测试隔离的自定义框架。
MVVM：ViewModel 通过绑定机制自动同步 View 和 Model。前端代表：Vue、Angular。

React 不是严格 MVVM，而是函数式 UI = f(state)。

评分维度：

三个角色职责清晰（40%）
能给出前端代表案例（30%）
能区分 React 与传统 MVVM（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

MVC：Model 负责数据，View 负责展示，Controller 接收输入并协调。前端代表：Backbone.js。 - MVP：Presenter 作为 View 和 Model 的中介，View 很薄。前端应用较少，多见于需要强测试隔离的自定义框架。

FB-25-CO-A-015：为什么前端需要 BFF？直接调用后端微服务有什么问题？

题目描述：为什么前端需要 BFF？直接调用后端微服务有什么问题。

参考答案：

直接调用后端的问题：

多端需求差异大，后端被迫为各端定制接口。
页面往往需要聚合多个服务，前端需要多次请求。
后端数据结构不一定适合前端展示，前端需要大量转换逻辑。
鉴权、限流、缓存等逻辑分散。

BFF 的价值：面向前端做接口聚合、数据适配、统一鉴权、缓存和降级。

评分维度：

能说出至少 3 个直接调用的问题（40%）
能说明 BFF 的核心价值（40%）
有边界判断意识（不是什么都走 BFF）（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

直接调用后端的问题： 1. 多端需求差异大，后端被迫为各端定制接口。 2. 页面往往需要聚合多个服务，前端需要多次请求。 3. 后端数据结构不一定适合前端展示，前端需要大量转换逻辑。 4. 鉴权、限流、缓存等逻辑分散。

FB-25-CO-A-016：什么是 DDD？前端如何借鉴 DDD 思想？

题目描述：什么是 DDD？前端如何借鉴 DDD 思想。

参考答案：

DDD（领域驱动设计）是以业务领域为核心组织软件设计的方法，核心概念包括实体、值对象、聚合、限界上下文、防腐层。

前端借鉴方式：

按业务领域拆分目录和模块，如 features/order、features/user，而不是按类型平铺 components/、services/。
定义领域模型，把业务规则放在模型中，例如 Order 实体封装金额计算、状态流转逻辑。
通过防腐层（Anti-Corruption Layer）隔离后端 DTO 与前端领域模型，避免后端字段变化直接影响业务代码。
与后端统一领域语言（Ubiquitous Language），如“订单”“履约”“退款”等术语前后端一致。
识别聚合根和限界上下文，避免跨模块直接引用内部实现。

适用边界：DDD 适合业务复杂、领域边界清晰的中大型项目；对于简单 CRUD 页面，不必强行引入。

评分维度：

能解释 DDD 核心概念（30%）
能结合前端落地（35%）
能说明防腐层和统一语言（20%）
能说明适用边界（15%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

DDD（领域驱动设计）是以业务领域为核心组织软件设计的方法，核心概念包括实体、值对象、聚合、限界上下文、防腐层。前端借鉴方式： 1. 按业务领域拆分目录和模块，如 features/order、features/user，而不是按类型平铺 components/、services/。 2. 定义领域模型，把业务规则放在模型中，例如 Order 实体封装金额计算、状态流转逻辑。 3. 通过防腐层（Anti-Corruption Layer）隔离后端 DTO 与前端领域模型，避免后端字段变化直接影响业务代码。

FB-25-CO-A-017：解释单一职责原则（SRP）在前端组件设计中的应用。

题目描述：解释单一职责原则（SRP）在前端组件设计中的应用。。

参考答案：

单一职责原则要求一个模块/组件只负责一件事。在前端中：

展示组件只负责渲染，不处理数据请求。
容器组件负责数据获取和状态管理。
工具函数只做单一功能。
业务逻辑下沉到 Service 或 Store。

好处是代码更易理解、测试和复用。

补充说明：

在实际落地解释单一职责原则（SRP）在前端组件设计中的应用。时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

理解 SRP 含义（30%）
能结合前端组件/模块举例（50%）
能说明好处（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

单一职责原则要求一个模块/组件只负责一件事。在前端中： - 展示组件只负责渲染，不处理数据请求。 - 容器组件负责数据获取和状态管理。 - 工具函数只做单一功能。

FB-25-CO-A-018：什么是依赖倒置原则？举一个前端代码示例。

题目描述：什么是依赖倒置原则？举一个前端代码示例。。

参考答案：

依赖倒置原则要求高层模块依赖抽象接口，而不是低层模块的具体实现。

示例：

typescript

interface Logger {
  log(msg: string): void;
}

class ConsoleLogger implements Logger {
  log(msg: string) { console.log(msg); }
}

class SentryLogger implements Logger {
  log(msg: string) { /* 上报 Sentry */ }
}

class OrderService {
  constructor(private logger: Logger) {}
  createOrder() {
    // ...
    this.logger.log('order created');
  }
}

// 测试
const testOrderService = new OrderService(new ConsoleLogger());
// 生产
const prodOrderService = new OrderService(new SentryLogger());

这样可以在测试时用 MockLogger，生产环境用 SentryLogger，而 OrderService 不需要修改。前端常见应用：HTTP 客户端抽象、埋点 SDK 抽象、存储抽象。

评分维度：

能准确解释原则（35%）
能写出符合原则的代码示例（35%）
能说明实际收益（20%）
能列举前端应用场景（10%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

依赖倒置原则要求高层模块依赖抽象接口，而不是低层模块的具体实现。示例：（代码示例）这样可以在测试时用 MockLogger，生产环境用 SentryLogger，而 OrderService 不需要修改。前端常见应用：HTTP 客户端抽象、埋点 SDK 抽象、存储抽象。

FB-25-CO-A-019：你如何理解“康威定律”？它对前端架构有什么影响？

题目描述：你如何理解“康威定律”？它对前端架构有什么影响。

参考答案：

康威定律指出：设计系统的组织，其产生的设计等价于组织间的沟通结构。简单说，团队结构会反映到代码结构中。

对前端架构的影响：

如果团队按业务领域划分，代码应该按领域拆分。
如果多个团队共享一个代码库，需要明确模块边界和 ownership。
微前端等架构往往是为了匹配多团队的组织结构。

评分维度：

能解释康威定律（40%）
能联系到团队与代码结构（40%）
有实际案例（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

康威定律指出：设计系统的组织，其产生的设计等价于组织间的沟通结构。简单说，团队结构会反映到代码结构中。对前端架构的影响： - 如果团队按业务领域划分，代码应该按领域拆分。 - 如果多个团队共享一个代码库，需要明确模块边界和 ownership。

FB-25-CO-A-020：分层架构中，UI 层、业务逻辑层、数据访问层各自应该做什么？

题目描述：分层架构中，UI 层、业务逻辑层、数据访问层各自应该做什么。

参考答案：

UI 层：负责界面渲染和用户交互，不直接处理数据获取。
业务逻辑层：负责状态管理、业务规则、流程编排。
数据访问层：负责与外部服务交互、数据转换、缓存、错误处理。

关键原则：上层可以依赖下层，下层不依赖上层；层与层之间通过稳定接口交互。

补充说明：

在实际落地分层架构中，UI 层、业务逻辑层、数据访问层各自应该做什么时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

三层职责清晰（50%）
能说明依赖方向（30%）
能举反例说明问题（20%）

二、高级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

UI 层：负责界面渲染和用户交互，不直接处理数据获取。 - 业务逻辑层：负责状态管理、业务规则、流程编排。 - 数据访问层：负责与外部服务交互、数据转换、缓存、错误处理。关键原则：上层可以依赖下层，下层不依赖上层；层与层之间通过稳定接口交互。

FB-25-SS-P-017：你在项目中如何落地模块化？遇到的最大挑战是什么？

题型：软技能题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：7-10 分钟

题目描述：你在项目中如何落地模块化？遇到的最大挑战是什么。

参考答案：

落地方式：

按业务领域或功能拆分目录。
定义清晰的模块接口，隐藏内部实现。
使用索引文件（index.ts）控制对外暴露的 API。
通过 ESLint/依赖检查工具限制跨模块引用。
建立公共组件库和工具库。

最大挑战：

历史代码耦合严重，拆分成本高。
模块边界难以一开始就定义准确。
团队成员对“公共”和“私有”的理解不一致。

评分维度：

有具体落地措施（50%）
能识别真实挑战（30%）
有持续改进意识（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

落地方式： 1. 按业务领域或功能拆分目录。 2. 定义清晰的模块接口，隐藏内部实现。 3. 使用索引文件（index.ts）控制对外暴露的 API。 4. 通过 ESLint/依赖检查工具限制跨模块引用。

FB-25-CO-P-014：什么是防腐层？为什么前端也需要它？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：7-10 分钟

题目描述：什么是防腐层？为什么前端也需要它。

参考答案：

防腐层是 DDD 中的模式，用于把外部模型转换为内部领域模型，防止外部变化污染内部业务。

前端需要防腐层的原因：

后端接口数据结构经常变化。
后端字段命名规范（snake_case）与前端（camelCase）不同。
后端返回的是通用模型，前端需要适配为展示模型。
多个后端服务的数据结构不一致。

通过防腐层，业务代码只依赖稳定的领域模型。

评分维度：

能解释防腐层目的（40%）
能列出前端需要它的原因（40%）
能写出简单适配示例（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

防腐层是 DDD 中的模式，用于把外部模型转换为内部领域模型，防止外部变化污染内部业务。前端需要防腐层的原因： - 后端接口数据结构经常变化。 - 后端字段命名规范（snake_case）与前端（camelCase）不同。 - 后端返回的是通用模型，前端需要适配为展示模型。

FB-25-SS-P-018：如何评估一个项目是否需要引入微前端？

题目描述：如何评估一个项目是否需要引入微前端。

参考答案：

适合引入微前端的场景：

多个独立团队维护不同业务域，需要独立部署。
技术栈差异大，需要渐进式迁移。
项目规模巨大，单一仓库构建和发布效率低下。
需要隔离不同子应用的故障影响面。

不适合的场景：

小团队、小项目，直接增加复杂度。
子应用间耦合严重，通信频繁。
没有独立部署需求。

评分维度：

能列出适用场景（40%）
能列出不适用场景（30%）
强调“按需引入”而非盲目跟风（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

适合引入微前端的场景： 1. 多个独立团队维护不同业务域，需要独立部署。 2. 技术栈差异大，需要渐进式迁移。 3. 项目规模巨大，单一仓库构建和发布效率低下。 4. 需要隔离不同子应用的故障影响面。

FB-25-SD-P-009：设计一个电商系统的前端状态管理方案，说明如何组织状态。

题型：系统设计题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：7-10 分钟

题目描述：设计一个电商系统的前端状态管理方案，说明如何组织状态。。

参考答案：

状态分层：

全局共享状态：用户信息、购物车数量、主题语言等，用全局 Store（如 Redux/Pinia）。
领域状态：订单列表、商品详情等，按领域模块划分 Store。
本地 UI 状态：弹窗开关、表单临时值，用组件内部 state。
服务端状态：来自 API 的数据，用 React Query/SWR 等专门管理。

组织原则：

服务端状态和客户端状态分离。
避免所有状态都放全局。
状态变更路径清晰，便于追踪。

补充说明：

在实际落地设计一个电商系统的前端状态管理方案，说明如何组织状态。时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

状态分层合理（40%）
能区分服务端与客户端状态（30%）
能结合具体业务举例（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

状态分层： 1. 全局共享状态：用户信息、购物车数量、主题语言等，用全局 Store（如 Redux/Pinia）。 2. 领域状态：订单列表、商品详情等，按领域模块划分 Store。 3. 本地 UI 状态：弹窗开关、表单临时值，用组件内部 state。 4. 服务端状态：来自 API 的数据，用 React Query/SWR 等专门管理。

FB-25-SS-P-019：你如何处理前端项目中的“技术债”？

题目描述：你如何处理前端项目中的“技术债”。

参考答案：

处理技术债的方法：

识别与分类：把技术债按影响程度分级（高/中/低）。
量化成本：评估维护成本和修复成本。
纳入迭代：每个迭代预留 10%-20% 时间还债。
先止血再重构：补充测试、建立门禁，避免重构引入回归。
文档化：记录债务原因、影响、计划。
避免新债：通过 Code Review、Lint、测试防止新增债务。

评分维度：

有系统化方法（50%）
强调先补测试再重构（20%）
有与业务方沟通的意识（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

处理技术债的方法： 1. 识别与分类：把技术债按影响程度分级（高/中/低）。 2. 量化成本：评估维护成本和修复成本。 3. 纳入迭代：每个迭代预留 10%-20% 时间还债。 4. 先止血再重构：补充测试、建立门禁，避免重构引入回归。

FB-25-CO-P-015：什么是“开闭原则”？前端中如何实现？

题目描述：什么是“开闭原则”？前端中如何实现。

参考答案：

开闭原则：对扩展开放，对修改关闭。即增加新功能时，尽量不修改已有代码，而是通过扩展实现。

前端实现方式：

插件化架构：通过注册插件扩展功能。
策略模式：把变化的行为封装为策略。
组合优于继承：用组合方式扩展组件。
配置化：通过配置而非硬编码支持新类型。

示例：表单校验规则通过配置新增，而不是改校验函数。

评分维度：

理解开闭原则（30%）
能列举前端实现方式（50%）
能举具体例子（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

开闭原则：对扩展开放，对修改关闭。即增加新功能时，尽量不修改已有代码，而是通过扩展实现。前端实现方式： - 插件化架构：通过注册插件扩展功能。 - 策略模式：把变化的行为封装为策略。

FB-25-SD-P-010：如何设计一个可扩展的前端组件库？

题目描述：如何设计一个可扩展的前端组件库。

参考答案：

设计要点：

原子化设计：Button、Input 等基础组件 + 业务组件分层。
统一 API 规范：命名、事件、插槽/children 模式一致。
可组合性：支持受控与非受控、支持自定义渲染。
主题与样式隔离：CSS 变量、Scoped CSS、主题配置。
文档与示例：Storybook 等工具保证文档同步。
版本管理：语义化版本，兼容策略清晰。
构建输出：支持 ESM/CJS/UMD，支持 Tree Shaking。

补充说明：

在实际落地设计一个可扩展的前端组件库时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

分层与规范意识（30%）
可扩展性设计（30%）
工程化与文档意识（40%）

三、架构级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

设计要点： 1. 原子化设计：Button、Input 等基础组件 + 业务组件分层。 2. 统一 API 规范：命名、事件、插槽/children 模式一致。 3. 可组合性：支持受控与非受控、支持自定义渲染。 4. 主题与样式隔离：CSS 变量、Scoped CSS、主题配置。

FB-25-SD-R-011：假设你要从零设计一个日活千万级的内容社区前端架构，你会关注哪些关键点？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：10-15 分钟

题目描述：假设你要从零设计一个日活千万级的内容社区前端架构，你会关注哪些关键点。

参考答案：

关键点：

性能：SSR/SSG、CDN、资源预加载、图片/视频优化、骨架屏。
可扩展性：微前端或模块化 Monorepo，支持多团队并行开发。
状态管理：服务端状态与客户端状态分离，缓存策略。
质量保障：自动化测试、灰度发布、监控告警。
安全：XSS/CSRF 防护、内容安全策略 CSP。
国际化与无障碍：多语言、SSR 适配、A11y。
可观测性：性能监控、错误追踪、用户行为分析。
容灾与降级：BFF 降级、静态化兜底、关键路径保障。

补充说明：

在实际落地假设你要从零设计一个日活千万级的内容社区前端架构，你会关注哪些关键点时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

覆盖多个维度（50%）
能说明关键决策理由（30%）
有优先级意识（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

关键点： 1. 性能：SSR/SSG、CDN、资源预加载、图片/视频优化、骨架屏。 2. 可扩展性：微前端或模块化 Monorepo，支持多团队并行开发。 3. 状态管理：服务端状态与客户端状态分离，缓存策略。 4. 质量保障：自动化测试、灰度发布、监控告警。

FB-25-CO-R-017：你在设计前端架构时，如何平衡“交付速度”和“代码质量”？

题型：概念题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：10-15 分钟

题目描述：你在设计前端架构时，如何平衡“交付速度”和“代码质量”。

参考答案：

平衡策略：

分层推进：MVP 阶段快速验证，稳定后逐步重构。
建立质量门禁：Lint、单元测试、Code Review 是底线，不因为赶进度而放弃。
识别核心路径：核心业务流程必须高质量，边缘功能可以适当妥协。
预留技术债偿还时间：每个迭代预留重构时间。
工具化提效：脚手架、组件库、自动化测试减少重复工作。
度量驱动：通过代码覆盖率、Bug 率、线上故障等指标持续改进。

评分维度：

有分层推进思路（30%）
质量底线意识（30%）
度量和持续改进意识（40%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

平衡策略： 1. 分层推进：MVP 阶段快速验证，稳定后逐步重构。 2. 建立质量门禁：Lint、单元测试、Code Review 是底线，不因为赶进度而放弃。 3. 识别核心路径：核心业务流程必须高质量，边缘功能可以适当妥协。 4. 预留技术债偿还时间：每个迭代预留重构时间。

FB-25-SS-R-015：如何在前端团队中推动架构规范的落地？

题型：软技能题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：10-15 分钟

题目描述：如何在前端团队中推动架构规范的落地。

参考答案：

推动方法：

建立共识：让团队理解规范的价值，而不是强制命令。
工具化：用 ESLint、Commit Lint、CI 门禁把规范自动化。
脚手架与模板：通过项目模板降低遵循规范的成本。
Code Review：把架构原则融入 Review checklist。
文档与培训：编写架构决策记录（ADR）和最佳实践文档。
小步快跑：先在最核心模块试点，再推广。
持续反馈：定期复盘规范执行效果，及时调整。

评分维度：

有人性化推动意识（30%）
工具化与自动化思路（40%）
持续迭代意识（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

推动方法： 1. 建立共识：让团队理解规范的价值，而不是强制命令。 2. 工具化：用 ESLint、Commit Lint、CI 门禁把规范自动化。 3. 脚手架与模板：通过项目模板降低遵循规范的成本。 4. Code Review：把架构原则融入 Review checklist。

FB-25-SC-R-012：如果你发现一个项目的架构严重影响了业务发展，但重写成本极高，你会怎么做？

题型：场景设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：10-15 分钟

题目描述：如果你发现一个项目的架构严重影响了业务发展，但重写成本极高，你会怎么做。

参考答案：

策略：

评估影响：量化架构问题对业务的影响（开发效率、稳定性、扩展性）。
找到杠杆点：识别哪些模块改进后收益最大，优先改造。
渐进式重构：不追求一次性重写，而是“绞杀者模式”逐步替换。
建立保护网：先补测试和监控，再动核心代码。
分阶段目标：把大目标拆成可交付的小目标，持续拿到正反馈。
争取资源：用数据和业务价值说服管理层投入时间。
保留旧系统稳定：新系统逐步接管，旧系统只维护不新增。

评分维度：

不盲目重写（30%）
有渐进式重构思路（40%）
重视测试、监控和业务价值（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

策略： 1. 评估影响：量化架构问题对业务的影响（开发效率、稳定性、扩展性）。 2. 找到杠杆点：识别哪些模块改进后收益最大，优先改造。 3. 渐进式重构：不追求一次性重写，而是“绞杀者模式”逐步替换。 4. 建立保护网：先补测试和监控，再动核心代码。

FB-25-EN-R-002：谈谈你对“前端工程化”的理解，它在前端架构中处于什么位置？

题型：工程化题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：10-15 分钟

题目描述：谈谈你对“前端工程化”的理解，它在前端架构中处于什么位置。

参考答案：

前端工程化是用工程方法提升前端开发效率、质量和可维护性的体系，包括：

构建工具：Webpack/Vite/Rollup
代码规范：ESLint/Prettier/TypeScript
版本管理：Git 工作流、Monorepo
测试体系：单元/集成/E2E
CI/CD：自动化构建、部署、灰度
监控与可观测性

它在架构中的位置：工程化是架构落地的保障。再好的架构设计，没有工程化支撑也难以持续执行。

补充说明：

在实际落地谈谈你对“前端工程化”的理解，它在前端架构中处于什么位置时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

能系统列举工程化内容（50%）
理解工程化与架构的关系（30%）
有实践经验（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

前端工程化是用工程方法提升前端开发效率、质量和可维护性的体系，包括： - 构建工具：Webpack/Vite/Rollup - 代码规范：ESLint/Prettier/TypeScript - 版本管理：Git 工作流、Monorepo - 测试体系：单元/集成/E2E - CI/CD：自动化构建、部署、灰度 - 监控与可观测性它在架构中的位置：工程化是架构落地的保障。再好的架构设计，没有工程化支撑也难以持续执行。

FB-25-SD-R-012：你如何评价一个前端架构设计的好坏？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：25 系统架构设计标签：架构评估、可维护性、可扩展性、性能、成本 出现频率：中频 预计回答时长：10-15 分钟

题目描述：你如何评价一个前端架构设计的好坏。

参考答案：

评价前端架构不能只看技术先进性，而要看它是否匹配业务阶段、团队能力和长期演进目标。可以从以下维度建立量化评估框架：

可维护性（Maintainability）
- 模块边界是否清晰，依赖关系是否可控（可用依赖图、圈复杂度度量）。
- 是否有统一的编码规范、代码审查机制和自动化测试覆盖。
- 新人上手成本：能否在 1-2 周内完成首个需求。
可扩展性（Scalability）
- 新增业务域或页面时，是否需要修改核心代码？是否遵循开闭原则。
- 插件化/微前端/Monorepo 等拆分策略是否能支持团队并行演进。
- 公共能力（组件库、工具函数、BFF）是否沉淀为可复用资产。
性能与体验（Performance）
- 首屏/可交互时间是否满足业务目标（如 LCP < 2.5s、INP < 200ms）。
- 构建产物体积、代码分割、缓存命中率是否持续监控。
- 弱网/低端设备下的降级体验是否到位。
可靠性（Reliability）
- 是否有错误边界、兜底渲染、灰度发布和快速回滚能力。
- 核心链路是否具备可观测性（日志、指标、链路追踪）。
- 异常场景（网络抖动、依赖超时、CDN 故障）是否有预案。
研发效率（Productivity）
- 本地启动、构建、测试、部署耗时是否在团队可接受范围。
- 工具链（脚手架、IDE、CI/CD）是否统一且可扩展。
- 文档、示例、Onboarding 是否完善。
成本与复杂度（Cost）
- 架构复杂度是否与业务规模匹配，避免为“未来可能”过度设计。
- 运维成本：服务器、CDN、构建集群、第三方服务费用。
- 机会成本：引入新技术对团队学习曲线和招聘的影响。

实践建议：

把上述维度量化为检查清单，在方案评审时逐项打分。
对关键指标设立基线（如构建时间 < 3min、单元测试覆盖率 > 70%），并定期回顾。
好的架构是“能随业务演化而持续还债、持续迭代”的架构，而非一步到位的完美设计。

评分维度：

多维评价意识（40%）：能覆盖可维护性、可扩展性、性能、可靠性等
量化与落地能力（35%）：能把维度转化为可观测指标和检查清单
业务与团队匹配度（25%）：能结合业务阶段、团队规模做取舍

常见错误：

只谈技术先进，忽视团队维护成本和业务价值。
用单一指标（如“用了微前端”）判断架构好坏。
忽略长期演进，追求一步到位的大重构。

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

评价维度： 1. 可维护性：代码是否易读、易改、易测试。 2. 可扩展性：新增功能是否容易，是否影响现有代码。 3. 性能：加载、渲染、交互是否流畅。 4. 可靠性：是否有容错、降级、监控。

FB-25-CP-R-014：什么时候应该选择 Server-Driven UI？它和低代码平台有什么区别？

难度：🟡

考察点：SDUI、低代码、架构选型。

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：25 系统架构设计标签：风险、前后端协作、Monorepo、微前端、模块化 出现频率：中频 预计回答时长：10-15 分钟

题目描述：什么时候应该选择 Server-Driven UI？它和低代码平台有什么区别？

难度：🟡

考察点：SDUI、低代码、架构选型。。

参考答案：

SDUI 适用场景：

页面结构需要服务端动态控制。
希望不发版即可调整 UI（如首页、活动页、卡片流）。
多端需要展示不同 UI 组合。
需要频繁做 A/B 测试。

与低代码平台的区别：

SDUI 的控制方是服务端/算法，根据请求动态下发；低代码的控制方是运营/产品经理通过编辑器配置。
SDUI 更强调“运行时动态”；低代码更强调“可视化配置”。
SDUI 适合 C 端动态页面；低代码适合后台系统和活动页搭建。

评分维度：

适用场景区分清晰（30%）
能与低代码对比（30%）
有前端实现经验（20%）
能讲出版本兼容和降级（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

SDUI 适用场景： - 页面结构需要服务端动态控制。 - 希望不发版即可调整 UI（如首页、活动页、卡片流）。 - 多端需要展示不同 UI 组合。 - 需要频繁做 A/B 测试。

FB-25-CP-R-015：微内核架构和微前端有什么区别？

难度：🟡

考察点：微内核、微前端、架构模式对比。

题目描述：微内核架构和微前端有什么区别？

难度：🟡

考察点：微内核、微前端、架构模式对比。。

参考答案：

补充说明：

在实际落地微内核架构和微前端有什么区别时，建议结合风险、前后端协作、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 微内核架构：

强调一个最小核心 + 可插拔插件。
插件通常共享同一技术栈和运行时。
适合构建可扩展的平台型产品（如 IDE、低代码平台）。

微前端架构：

强调把前端应用拆成独立部署的子应用。
子应用可以用不同技术栈。
适合多团队并行开发的大型 Web 应用。

关系：微前端可以看作是微内核思想在前端工程化中的一种实现方式。

评分维度：

概念准确（30%）
能讲清核心差异（30%）
有适用场景判断（20%）
能结合团队组织分析（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

微内核架构： - 强调一个最小核心 + 可插拔插件。 - 插件通常共享同一技术栈和运行时。 - 适合构建可扩展的平台型产品（如 IDE、低代码平台）。微前端架构： - 强调把前端应用拆成独立部署的子应用。

FB-25-CO-R-018：什么是六边形架构？它如何解决前端测试难的问题？

难度：🟡

考察点：六边形架构、整洁架构、可测试性。

题目描述：什么是六边形架构？它如何解决前端测试难的问题？

难度：🟡

考察点：六边形架构、整洁架构、可测试性。。

参考答案：

六边形架构（Hexagonal Architecture）又称端口与适配器架构，核心思想是：

业务逻辑位于中心，不依赖框架、UI 和外部服务。
通过定义端口（抽象接口）与外部交互。
适配器实现端口，负责具体技术细节。

解决前端测试难：

业务逻辑可以脱离浏览器、React、API 单独测试。
UI 层只依赖应用层和端口，可以用 Mock 适配器测试。
适配器单独测试，确保与外部系统交互正确。

评分维度：

核心思想解释清晰（30%）
能说明端口与适配器（30%）
测试收益具体（20%）
有项目落地经验（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

六边形架构（Hexagonal Architecture）又称端口与适配器架构，核心思想是： - 业务逻辑位于中心，不依赖框架、UI 和外部服务。 - 通过定义端口（抽象接口）与外部交互。 - 适配器实现端口，负责具体技术细节。解决前端测试难： - 业务逻辑可以脱离浏览器、React、API 单独测试。

FB-25-CP-R-016：面对一个复杂业务系统，你会如何选择前端架构模式？

难度：🔴

考察点：架构选型、决策框架、综合能力。

题目描述：面对一个复杂业务系统，你会如何选择前端架构模式？

难度：🔴

考察点：架构选型、决策框架、综合能力。。

参考答案：

选型步骤：

理解业务：业务复杂度、变化频率、多端需求、团队规模。
识别约束：性能要求、安全要求、技术栈约束、人员能力。
列出候选：MVC/MVVM、BFF、DDD、微前端、微内核、SDUI、低代码、事件驱动、六边形架构等。
评估打分：从业务契合度、团队能力、可维护性、性能影响、生态成熟度等维度评分。
做 POC 验证：对关键风险点做原型验证。
输出 ADR：记录决策过程、备选方案、trade-off。

常见判断：

多端 + 多团队 → 微前端 + Monorepo
高度模式化页面 → 低代码/搭建体系
服务端动态控制 UI → SDUI
复杂业务规则 + 长期演进 → DDD + 六边形架构
强事件流/UndoRedo → 事件驱动/CQRS

评分维度：

选型流程系统（30%）
能结合具体场景推荐模式（30%）
有风险和 trade-off 意识（20%）
有 ADR/POC 意识（20%）

领域编号：A01 应用架构模式
最后更新：2026-06-24

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

选型步骤： 1. 理解业务：业务复杂度、变化频率、多端需求、团队规模。 2. 识别约束：性能要求、安全要求、技术栈约束、人员能力。 3. 列出候选：MVC/MVVM、BFF、DDD、微前端、微内核、SDUI、低代码、事件驱动、六边形架构等。 4. 评估打分：从业务契合度、团队能力、可维护性、性能影响、生态成熟度等维度评分。

FB-25-CO-A-021：MVC、MVVM、MVP、MVI 的取舍与前端映射

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：架构模式、MVC、MVVM、单向数据流、状态管理 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请比较四种架构模式的核心差异，并说明在 Vue/React 等现代框架中如何落地。

参考答案：

核心思路如下：

MVC：View 与 Model 可能直接耦合，Controller 负责输入映射
MVVM：通过 ViewModel 与响应式绑定解耦 View 和 Model，Vue 是典型代表
MVP：Presenter 作为中介，View 被动，测试性好但样板代码多
MVI：基于不可变 State 与单向数据流，用户 Intent → Model → View 闭环
现代框架多为 MVVM + 单向数据流混合，选型以团队可维护性为准

需要避免的典型误区：

把 React 直接等同于 MVC
认为 MVVM 就是双向绑定，忽略 ViewModel 抽象
把 MVI 与 MVVM 混为一谈

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：MVC、MVVM 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

把 React 直接等同于 MVC
认为 MVVM 就是双向绑定，忽略 ViewModel 抽象
把 MVI 与 MVVM 混为一谈

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

MVC；MVVM；MVP；MVI；现代框架多为 MVVM + 单向数据流混合，选型以团队可维护性为准。同时要避免把 React 直接等同于 MVC。

FB-25-CO-B-017：什么是 BFF（Backend for Frontend）

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：25 系统架构设计标签：BFF、前后端协作、API 适配、多端 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 BFF 的概念、解决的问题，以及前端与 BFF 的协作方式。

参考答案：

核心思路如下：

BFF 是面向前端的后端层，负责聚合、裁剪、鉴权透传
解决接口碎片化、多端差异、前后端耦合、多次请求性能问题
可按端或业务域拆分 BFF，对外暴露 REST/GraphQL
BFF 不应包含核心领域逻辑，只负责适配

需要避免的典型误区：

BFF 里写业务规则
所有端共用一份 BFF 导致字段爆炸
把 BFF 当作简单代理，不做聚合

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：BFF 是面向前端的后端层，负责聚合、裁剪、鉴权透传、解决接口碎片化、多端差异、前后端耦合、多次请求性能问题等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

BFF 里写业务规则
所有端共用一份 BFF 导致字段爆炸
把 BFF 当作简单代理，不做聚合

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

BFF 是面向前端的后端层，负责聚合、裁剪、鉴权透传；解决接口碎片化、多端差异、前后端耦合、多次请求性能问题；可按端或业务域拆分 BFF，对外暴露 REST/GraphQL；BFF 不应包含核心领域逻辑，只负责适配。同时要避免BFF 里写业务规则。

FB-25-CO-P-016：整洁架构与六边形架构如何在前端落地

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：Clean Architecture、六边形架构、依赖倒置、领域层 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请说明 Clean Architecture / Hexagonal Architecture 的核心思想，并给出前端项目的目录与依赖设计。

参考答案：

核心思路如下：

核心思想：领域层不依赖框架、UI、数据库，依赖方向向内
前端映射：domain/use-case 位于核心，frameworks/ui 位于外层
通过端口（interface）与适配器（adapter）隔离外部 API、存储、组件库
目录示例：domain → application → adapters → ui/framework
收益：可测试、可替换 UI 框架、业务逻辑复用

需要避免的典型误区：

在小项目中过度分层
领域层直接 import UI 组件
接口设计不稳定，替换成本依然高

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：核心思想、前端映射等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

在小项目中过度分层
领域层直接 import UI 组件
接口设计不稳定，替换成本依然高

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

核心思想；前端映射；通过端口（interface）与适配器（adapter）隔离外部 API、存储、组件库；目录示例；收益。同时要避免在小项目中过度分层。

FB-25-SC-A-012：大型中后台系统如何进行模块拆分

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：模块拆分、Monorepo、业务域、依赖关系、构建 出现频率：高频 预计回答时长：8-15 分钟

题目描述：一个拥有上百个页面的中后台系统， monolith 导致构建慢、冲突多。请给出模块拆分方案。

参考答案：

核心思路如下：

按业务域（订单、商品、用户）拆分为独立包或子应用
使用 Monorepo + pnpm workspace 管理共享依赖
公共层下沉：UI 组件库、工具库、API 客户端独立发布
构建侧：按需构建受影响包，远程缓存加速
运行时集成：可选微前端或路由懒加载，保持用户体验一致

需要避免的典型误区：

按技术层（components/utils）而非业务域拆分
拆分后仍互相直接引用内部实现
没有统一版本管理，子模块升级失控

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：按业务域（订单、商品、用户）拆分为独立包或子应用、使用 Monorepo + pnpm workspace 管理共享依赖等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

按技术层（components/utils）而非业务域拆分
拆分后仍互相直接引用内部实现
没有统一版本管理，子模块升级失控

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

一个拥有上百个页面的中后台系统， monolith 导致构建慢、冲突多。按业务域（订单、商品、用户）拆分为独立包或子应用；使用 Monorepo + pnpm workspace 管理共享依赖；公共层下沉；构建侧；运行时集成。同时要避免按技术层（components/utils）而非业务域拆分。

FB-25-SD-R-013：设计一个支持多终端的 BFF 层

题型：系统设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：BFF、多端、API 聚合、GraphQL、缓存 出现频率：高频 预计回答时长：15-30 分钟

题目描述：请为 Web、App、小程序、运营后台设计统一的 BFF 架构，兼顾差异与复用。

参考答案：

核心思路如下：

抽象设备无关的核心数据模型，BFF 负责映射到各端视图模型
按端提供独立 BFF 入口，共享通用 Service 层
使用 GraphQL 或聚合接口减少请求数，注意 N+1 与缓存
统一鉴权、限流、日志、trace_id 透传
监控各端接口耗时、错误率，按端发布回滚

需要避免的典型误区：

所有端共用字段导致 App 包变大
BFF 泄露核心领域逻辑
多端差异大却强统一数据模型

补充说明：

在实际落地设计一个支持多终端的 BFF 层时，建议结合 BFF、多端、API 聚合的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：抽象设备无关的核心数据模型，BFF 负责映射到各端视图模型、按端提供独立 BFF 入口，共享通用 Service 层等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有端共用字段导致 App 包变大
BFF 泄露核心领域逻辑
多端差异大却强统一数据模型

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

抽象设备无关的核心数据模型，BFF 负责映射到各端视图模型；按端提供独立 BFF 入口，共享通用 Service 层；使用 GraphQL 或聚合接口减少请求数，注意 N+1 与缓存；统一鉴权、限流、日志、trace_id 透传；监控各端接口耗时、错误率，按端发布回滚。同时要避免所有端共用字段导致 App 包变大。

FB-25-CO-A-022：什么是防腐层（Anti-Corruption Layer）

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：防腐层、DDD、适配器、领域模型 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释防腐层的作用，并举例说明前端如何用它隔离外部 API 对领域模型的污染。

参考答案：

核心思路如下：

ACL 用于把外部模型转换为本领域模型，防止外部变化扩散
前端例子：后端返回 snake_case 数据库字段，ACL 转为领域对象
放置位置：靠近数据入口（repository / api adapter），不进入业务逻辑
使用 mapper 函数或类，集中处理字段映射与默认值
当外部接口升级时，只需改 ACL

需要避免的典型误区：

在每个组件里做字段转换
ACL 里写业务规则
领域模型直接使用后端 DTO

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：ACL 用于把外部模型转换为本领域模型，防止外部变化扩散、前端例子等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

在每个组件里做字段转换
ACL 里写业务规则
领域模型直接使用后端 DTO

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

ACL 用于把外部模型转换为本领域模型，防止外部变化扩散；前端例子；放置位置；使用 mapper 函数或类，集中处理字段映射与默认值；当外部接口升级时，只需改 ACL。同时要避免在每个组件里做字段转换。

FB-25-SC-P-012：前端如何应对高并发秒杀活动的流量峰值

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：高并发、秒杀、限流、降级、CDN、缓存 出现频率：中频 预计回答时长：8-15 分钟

题目描述：某电商大促秒杀页面预计 QPS 极高，请从前后端协作角度给出前端架构方案。

参考答案：

核心思路如下：

静态资源预热：HTML/JS/CSS 推送到 CDN 并启用强缓存
前端限流：倒计时后统一放行、令牌桶控制按钮点击
请求合并与去重：避免重复提交，幂等 key 防止超卖
降级策略：库存接口熔断时展示缓存数据或排队页
监控：上报点击率、下单转化率、接口错误率，实时调整

需要避免的典型误区：

靠前端单独扛流量，不协同后端限流
秒杀按钮不做防抖导致重复提交
缓存数据不提示用户可能过期

补充说明：

在实际落地前端如何应对高并发秒杀活动的流量峰值时，建议结合高并发、秒杀、限流的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：静态资源预热、前端限流等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

靠前端单独扛流量，不协同后端限流
秒杀按钮不做防抖导致重复提交
缓存数据不提示用户可能过期

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

某电商大促秒杀页面预计 QPS 极高，静态资源预热；前端限流；请求合并与去重；降级策略；监控。同时要避免靠前端单独扛流量，不协同后端限流。

FB-25-SD-A-013：设计一个前端错误边界与降级渲染体系

题型：系统设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：错误边界、降级、容错、监控、React 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请设计一套前端错误处理体系，覆盖运行时错误、异步错误、子应用错误，并说明降级策略。

参考答案：

核心思路如下：

同步渲染错误：React Error Boundary / Vue errorHandler
异步错误：Promise catch、全局 unhandledrejection、fetch 拦截器
资源错误：window error 捕获阶段监听
子应用错误：微前端基座捕获生命周期异常
降级分级：组件级占位、页面级错误页、子应用级切换备用
监控联动：上报 componentStack、trace_id、版本，按 fingerprint 聚合

需要避免的典型误区：

只用 window.onerror 捕获所有错误
错误边界内直接白屏
错误信息缺少上下文

补充说明：

在实际落地设计一个前端错误边界与降级渲染体系时，建议结合错误边界、降级、容错的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：同步渲染错误、异步错误等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只用 window.onerror 捕获所有错误
错误边界内直接白屏
错误信息缺少上下文

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

同步渲染错误；异步错误；资源错误；子应用错误；降级分级；监控联动。同时要避免只用 window.onerror 捕获所有错误。

FB-25-EN-A-015：如何设计前端项目的 CI/CD 流水线

题型：工程化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：CI/CD、流水线、质量门禁、自动化、部署 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请为一个中型前端团队设计 CI/CD 流水线，覆盖代码提交到生产发布的完整流程。

参考答案：

核心思路如下：

触发：Push / MR / 定时 / 手动
静态检查：ESLint、Prettier、TypeScript、依赖审计
测试：单元测试、集成测试、E2E 核心路径
构建产物分析：包体积预算、重复依赖检测
部署预览：MR 自动生成 preview
发布：灰度 -> 全量，保留上一版本 CDN 目录用于回滚

需要避免的典型误区：

CI 只跑构建不跑测试
包体积无限制
生产发布无灰度

补充说明：

在实际落地设计前端项目的 CI/CD 流水线时，建议结合 CI/CD、流水线、质量门禁的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：触发、静态检查等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

CI 只跑构建不跑测试
包体积无限制
生产发布无灰度

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

触发；静态检查；测试；构建产物分析；部署预览；发布。同时要避免CI 只跑构建不跑测试。

FB-25-SS-R-016：作为前端架构师如何推动架构落地

题型：软技能题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：跨团队协作、架构师、沟通、影响力、推动落地 出现频率：中频 预计回答时长：8-15 分钟

题目描述：在推动跨团队前端架构改造时，你如何与后端、产品、运维协作并处理分歧？

参考答案：

核心思路如下：

用业务语言描述收益，与各团队 OKR 对齐
召开 RFC 评审，让后端、运维、QA、产品参与
先找痛点团队试点，跑出案例再推广
提供脚手架、文档、培训，降低接入成本
用数据和 PoC 处理技术分歧，向管理层沟通资源分歧

需要避免的典型误区：

只从技术角度推动
方案确定后才通知相关团队
遇到阻力就放弃

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：用业务语言描述收益，与各团队 OKR 对齐、召开 RFC 评审，让后端、运维、QA、产品参与等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只从技术角度推动
方案确定后才通知相关团队
遇到阻力就放弃

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

在推动跨团队前端架构改造时，你如何与后端、产品、运维协作并处理分歧？用业务语言描述收益，与各团队 OKR 对齐；召开 RFC 评审，让后端、运维、QA、产品参与；先找痛点团队试点，跑出案例再推广；提供脚手架、文档、培训，降低接入成本；用数据和 PoC 处理技术分歧，向管理层沟通资源分歧。同时要避免只从技术角度推动。

FB-25-CO-P-017：Bounded Context 如何映射到前端架构

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：Bounded Context、DDD、前端拆分、领域边界 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释 DDD 中的 Bounded Context，并说明它与微前端、组件库的关系。

参考答案：

核心思路如下：

Bounded Context 是明确业务边界，内部有自己的领域模型和通用语言
前端按业务域拆分模块或应用，模块内部自治
上下文间通过事件、URL、防腐层集成
与微前端：Context 是业务划分依据，微前端是技术集成手段
组件库是技术复用，不应包含业务领域知识

需要避免的典型误区：

把技术层当业务上下文拆分
所有子应用共享同一领域模型
组件库里混入业务逻辑

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Bounded Context 是明确业务边界，内部有自己的领域模型和通用语言、前端按业务域拆分模块或应用，模块内部自治等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

把技术层当业务上下文拆分
所有子应用共享同一领域模型
组件库里混入业务逻辑

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Bounded Context 是明确业务边界，内部有自己的领域模型和通用语言；前端按业务域拆分模块或应用，模块内部自治；上下文间通过事件、URL、防腐层集成；与微前端；组件库是技术复用，不应包含业务领域知识。同时要避免把技术层当业务上下文拆分。

FB-25-CO-A-023：什么是 Circuit Breaker，前端如何配合

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：熔断、降级、容错、可靠性、失败模式 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释熔断机制的原理和状态机，并说明前端在调用后端服务时如何配合。

参考答案：

核心思路如下：

熔断状态：Closed（正常）、Open（快速失败）、Half-Open（探测）
前端识别网关返回的 503/429 或特定 header
熔断时展示缓存、默认推荐或友好提示
幂等请求可有限重试，非幂等请求不重试
上报熔断触发次数和用户体验影响

需要避免的典型误区：

非幂等请求自动重试
熔断后无任何 UI 反馈
把熔断当作家常便饭

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：熔断状态、前端识别网关返回的 503/429 或特定 header 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

非幂等请求自动重试
熔断后无任何 UI 反馈
把熔断当作家常便饭

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

熔断状态；前端识别网关返回的 503/429 或特定 header；熔断时展示缓存、默认推荐或友好提示；幂等请求可有限重试，非幂等请求不重试；上报熔断触发次数和用户体验影响。同时要避免非幂等请求自动重试。

FB-25-SC-A-013：前端应用灰度发布的技术方案

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：灰度发布、Canary、Feature Flag、回滚、监控 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请设计一个前端应用的灰度发布方案，支持按用户、地域、流量比例放量。

参考答案：

核心思路如下：

灰度标识：cookie/header/用户 ID 哈希分桶
资源版本化：JS/CSS 带 hash，新旧版本共存 CDN
放量策略：百分比、白名单、地域、业务属性逐步扩大
监控：错误率、核心转化率、性能指标
回滚：切换流量或回退 Feature Flag，无需重新发版

需要避免的典型误区：

随机分桶导致同一用户前后版本不同
只放量不看指标
回滚需要重新发版

补充说明：

在实际落地前端应用灰度发布的技术方案时，建议结合灰度发布、Canary、Feature Flag 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：灰度标识、资源版本化等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

随机分桶导致同一用户前后版本不同
只放量不看指标
回滚需要重新发版

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

灰度标识；资源版本化；放量策略；监控；回滚。同时要避免随机分桶导致同一用户前后版本不同。

FB-25-CP-R-017：如何在组织中推进前端架构升级

题型：综合开放题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：架构升级、组织推动、技术债、治理、ROI 出现频率：高频 预计回答时长：15-30 分钟

题目描述：公司技术债严重，你计划推进一次大规模前端架构升级。请说明策略和风险控制。

参考答案：

核心思路如下：

明确目标与度量：构建时长、错误率、交付周期、性能
分阶段：试点 -> 标杆业务 -> 全面推广
建立治理组织：前端技术委员会、架构评审
提供迁移工具、文档、培训，降低接入成本
风险控制：保留旧版本、Feature Flag、灰度回滚、业务影响兜底

需要避免的典型误区：

一上来要求所有老项目重写
只定规范没有工具
忽视团队学习成本

补充说明：

在实际落地在组织中推进前端架构升级时，建议结合架构升级、组织推动、技术债的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：明确目标与度量、分阶段等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

一上来要求所有老项目重写
只定规范没有工具
忽视团队学习成本

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

公司技术债严重，你计划推进一次大规模前端架构升级。明确目标与度量；分阶段；建立治理组织；提供迁移工具、文档、培训，降低接入成本；风险控制。同时要避免一上来要求所有老项目重写。

FB-25-EN-R-003：如何设计前端标准化工具链

题型：工程化题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：工程化、工具链、标准化、CLI、模板、CI 出现频率：中频 预计回答时长：8-15 分钟

题目描述：公司前端技术栈多样、构建配置不统一。请设计一套标准化工具链及推广策略。

参考答案：

核心思路如下：

脚手架 CLI 内置项目类型：中后台、H5、微前端子应用
共享配置包：eslint-config、tsconfig、vite-config
统一流程：提交规范、Changeset、MR 模板、CI 流水线
可观测：构建产物分析、性能预算、CVE 扫描
推广：旧项目渐进接入，接入率纳入 OKR

需要避免的典型误区：

标准化变成僵化，不允许特例
只提供规范没有工具
强制一刀切

补充说明：

在实际落地设计前端标准化工具链时，建议结合工程化、工具链、标准化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：脚手架 CLI 内置项目类型、共享配置包等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

标准化变成僵化，不允许特例
只提供规范没有工具
强制一刀切

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

公司前端技术栈多样、构建配置不统一。脚手架 CLI 内置项目类型；共享配置包；统一流程；可观测；推广。同时要避免标准化变成僵化，不允许特例。

FB-25-CO-A-024：前端架构中的 Idempotency 是什么意思

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：幂等、接口设计、重试、一致性 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释幂等性在前端架构中的意义，以及哪些前端操作需要保证幂等。

参考答案：

核心思路如下：

幂等：同一操作执行多次与一次效果相同
前端场景：表单提交、支付、点赞、同步请求
通过唯一请求 ID（idempotency-key）让服务端识别重复
重试策略：幂等可自动重试，非幂等需提示用户确认
本地操作日志也可利用幂等实现离线同步

需要避免的典型误区：

所有请求都自动重试
幂等 key 由前端生成但不保证唯一
认为 GET 天然幂等就忽略其他方法

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：幂等、前端场景等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有请求都自动重试
幂等 key 由前端生成但不保证唯一
认为 GET 天然幂等就忽略其他方法

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

幂等；前端场景；通过唯一请求 ID（idempotency-key）让服务端识别重复；重试策略；本地操作日志也可利用幂等实现离线同步。同时要避免所有请求都自动重试。

FB-25-SC-P-013：微服务架构下前端的数据一致性策略

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：数据一致性、Saga、补偿、最终一致、微服务 出现频率：中频 预计回答时长：8-15 分钟

题目描述：前端调用多个微服务完成业务流程时可能部分成功。请说明一致性方案。

参考答案：

核心思路如下：

跨服务操作交给 BFF/Saga 编排，避免前端处理分布式事务
最终一致性：本地乐观更新，后台异步补偿
提供状态查询接口，让用户刷新查看最终结果
超时请求采用“先查后重试”，避免盲目重发

需要避免的典型误区：

前端串行调多个服务自己处理补偿
失败时直接提示成功
对非幂等接口超时后自动重试

补充说明：

在实际落地微服务架构下前端的数据一致性策略时，建议结合数据一致性、Saga、补偿的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：跨服务操作交给 BFF/Saga 编排，避免前端处理分布式事务、最终一致性等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

前端串行调多个服务自己处理补偿
失败时直接提示成功
对非幂等接口超时后自动重试

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

前端调用多个微服务完成业务流程时可能部分成功。跨服务操作交给 BFF/Saga 编排，避免前端处理分布式事务；最终一致性；提供状态查询接口，让用户刷新查看最终结果；超时请求采用“先查后重试”，避免盲目重发。同时要避免前端串行调多个服务自己处理补偿。

FB-25-CO-A-025：什么是 Service Mesh，前端需要关注吗

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：Service Mesh、Istio、Sidecar、微服务、网络 出现频率：低频 预计回答时长：3-5 分钟

题目描述：请解释 Service Mesh 的核心能力，并说明前端架构师是否需要关注。

参考答案：

核心思路如下：

Service Mesh 通过 Sidecar 提供服务发现、负载均衡、熔断、限流、加密、可观测
前端通常不直接部署 Sidecar，但需关注网关行为变化
协作点：trace_id 透传、CORS、超时、重试策略
边缘网关或 BFF 层也可能用到类似理念

需要避免的典型误区：

认为 Service Mesh 是前端技术
忽略 Sidecar 引入的延迟
Header 透传规则改变导致调试困难

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Service Mesh 通过 Sidecar 提供服务发现、负载均衡、熔断、限流、加密、可观测、前端通常不直接部署 Sidecar，但需关注网关行为变化等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

认为 Service Mesh 是前端技术
忽略 Sidecar 引入的延迟
Header 透传规则改变导致调试困难

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Service Mesh 通过 Sidecar 提供服务发现、负载均衡、熔断、限流、加密、可观测；前端通常不直接部署 Sidecar，但需关注网关行为变化；协作点；边缘网关或 BFF 层也可能用到类似理念。同时要避免认为 Service Mesh 是前端技术。

FB-25-SD-R-014：设计一个前端组件库/设计系统架构

题型：系统设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：组件库、设计系统、Monorepo、Token、主题 出现频率：高频 预计回答时长：15-30 分钟

题目描述：请设计一个企业级前端组件库，覆盖组件分层、主题定制、文档、测试、发布。

参考答案：

核心思路如下：

分层：Token -> 基础组件 -> 业务组件 -> 页面模板
Monorepo：core、theme、icons、docs、playground
主题：CSS Variables / JS Token，支持品牌色、暗色模式
文档：Storybook + 视觉回归 + 自动提取 Props
测试：单元、快照、a11y；发布：changeset + CI 自动发布

需要避免的典型误区：

组件库依赖业务逻辑
主题硬编码
只重开发不重文档测试

补充说明：

在实际落地设计一个前端组件库/设计系统架构时，建议结合组件库、设计系统、Monorepo 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：分层、Monorepo 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

组件库依赖业务逻辑
主题硬编码
只重开发不重文档测试

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

分层；Monorepo；主题；文档；测试。同时要避免组件库依赖业务逻辑。

FB-25-CP-R-018：前端架构如何应对业务高速变化和不确定性

题型：综合开放题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：演进式架构、可扩展性、插件化、Feature Flag 出现频率：中频 预计回答时长：15-30 分钟

题目描述：业务方向频繁调整，前端架构如何快速响应又避免过度设计？

参考答案：

核心思路如下：

演进式架构：核心域稳定，可变部分用插件/配置/Feature Flag 隔离
延迟决策：对不确定需求保留扩展点
模块化与接口稳定，内部实现可替换
A/B 测试验证假设，失败快速回滚
技术债管理：区分战略债与偶然债

需要避免的典型误区：

为不确定未来过度抽象
业务一变就推翻重来
忽视技术债

补充说明：

在实际落地前端架构如何应对业务高速变化和不确定性时，建议结合演进式架构、可扩展性、插件化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：演进式架构、延迟决策等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

为不确定未来过度抽象
业务一变就推翻重来
忽视技术债

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

业务方向频繁调整，前端架构如何快速响应又避免过度设计？演进式架构；延迟决策；模块化与接口稳定，内部实现可替换；A/B 测试验证假设，失败快速回滚；技术债管理。同时要避免为不确定未来过度抽象。

FB-25-EN-P-016：前端如何实现可重复可审计的构建与发布

题型：工程化题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：可重复构建、SBOM、签名、审计、CI/CD 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请说明如何通过工程化手段保证前端构建产物可重复、可审计，并防止篡改。

参考答案：

核心思路如下：

锁定依赖：lockfile + 固定 Node 版本 + 固定 CI 镜像
可重复构建：清理环境变量、禁用非确定性行为、比对 hash
产物签名：构建产物哈希清单，发布时签名
SBOM：记录依赖和构建工具清单
审计日志：构建人、时间、commit、参数可追溯

需要避免的典型误区：

每次构建依赖 latest
产物不上传 hash
缺少源码到产物映射

补充说明：

在实际落地前端如何实现可重复可审计的构建与发布时，建议结合可重复构建、SBOM、签名的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：锁定依赖、可重复构建等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

每次构建依赖 latest
产物不上传 hash
缺少源码到产物映射

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

锁定依赖；可重复构建；产物签名；SBOM；审计日志。同时要避免每次构建依赖 latest。

FB-25-SC-P-014：设计一个支持离线使用的复杂表单系统

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：离线优先、表单、本地存储、同步、冲突 出现频率：中频 预计回答时长：8-15 分钟

题目描述：现场作业应用网络不稳定，需要表单离线可用、联网后自动同步。请设计前端架构。

参考答案：

核心思路如下：

本地优先：表单状态保存在 IndexedDB，所有操作先写本地
变更日志：记录每个字段修改，支持撤销与冲突合并
同步策略：比较本地与服务端版本，按业务规则合并
队列与重试：提交请求排队；非幂等操作加 idempotency-key
草稿与提交：自动保存草稿，用户可主动提交

需要避免的典型误区：

离线时不做校验
直接覆盖服务端数据
同步失败不提示用户

补充说明：

在实际落地设计一个支持离线使用的复杂表单系统时，建议结合离线优先、表单、本地存储的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：本地优先、变更日志等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

离线时不做校验
直接覆盖服务端数据
同步失败不提示用户

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

现场作业应用网络不稳定，需要表单离线可用、联网后自动同步。本地优先；变更日志；同步策略；队列与重试；草稿与提交。同时要避免离线时不做校验。

FB-25-CO-P-018：API Composition 与 GraphQL BFF 的取舍

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：API Composition、GraphQL、BFF、数据聚合 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请比较 RESTful BFF 的接口聚合与 GraphQL BFF 的 API 组合，分析适用场景。

参考答案：

核心思路如下：

API Composition：编排层调用多个下游服务组合前端需要的数据
GraphQL BFF：前端按需查询字段，BFF 负责 resolver 聚合
REST 简单、缓存友好；端增多、字段冗余
GraphQL 减少请求和字段裁剪；缓存复杂、N+1、学习成本高
多端差异大且查询灵活用 GraphQL；接口稳定、缓存要求高用 REST

需要避免的典型误区：

GraphQL 解决所有问题
REST BFF 大量字段裁剪
N+1 未做 DataLoader 优化

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：API Composition、GraphQL BFF 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

GraphQL 解决所有问题
REST BFF 大量字段裁剪
N+1 未做 DataLoader 优化

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

API Composition；GraphQL BFF；REST 简单、缓存友好；端增多、字段冗余；GraphQL 减少请求和字段裁剪；缓存复杂、N+1、学习成本高；多端差异大且查询灵活用 GraphQL；接口稳定、缓存要求高用 REST。同时要避免GraphQL 解决所有问题。

FB-25-SD-R-015：设计一个前端性能监控与预警平台

题型：系统设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：性能监控、RUM、预警、Web Vitals、可观测 出现频率：中频 预计回答时长：15-30 分钟

题目描述：请为大型产品前端设计性能监控平台，覆盖采集、指标、告警和治理闭环。

参考答案：

核心思路如下：

采集层：web-vitals、Performance API、长任务、资源 timing
聚合层：按页面、版本、地区、设备分组，计算 P50/P75/P95
展示层：趋势图、热力图、下钻到单条 trace
告警层：P75 阈值、异常波动、发布关联告警
治理闭环：告警 -> 定位 -> 修复 -> 回归验证 -> 更新基线

需要避免的典型误区：

只看平均值忽略长尾
告警阈值过严导致疲劳
不关联发布版本

补充说明：

在实际落地设计一个前端性能监控与预警平台时，建议结合性能监控、RUM、预警的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：采集层、聚合层等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只看平均值忽略长尾
告警阈值过严导致疲劳
不关联发布版本

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

采集层；聚合层；展示层；告警层；治理闭环。同时要避免只看平均值忽略长尾。

FB-25-CO-A-026：什么是金丝雀发布，前端如何实现

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：金丝雀发布、灰度、Canary、监控、回滚 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释金丝雀发布的概念，并说明前端应用实现金丝雀发布的技术方案。

参考答案：

核心思路如下：

金丝雀：先让少量用户使用新版本，观察指标后再全量
实现：CDN/边缘按百分比或用户特征返回新版本 HTML，或用 Feature Flag
关键：分桶一致、监控完善、可回滚
指标：错误率、核心流程成功率、性能
资源带版本 hash，新旧版本可共存 CDN

需要避免的典型误区：

随机分桶导致用户看到不同版本
只放量不看指标
回滚需要重新发版

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：金丝雀、实现等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

随机分桶导致用户看到不同版本
只放量不看指标
回滚需要重新发版

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

金丝雀；实现；关键；指标；资源带版本 hash，新旧版本可共存 CDN。同时要避免随机分桶导致用户看到不同版本。

FB-25-SC-A-014：如何设计一个可扩展的权限前端架构

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：权限、RBAC、ABAC、路由守卫、按钮级权限 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请设计前端权限系统，支持菜单、路由、按钮、数据字段等多维度控制。

参考答案：

核心思路如下：

模型：RBAC 适合简单场景，ABAC 适合复杂动态场景
数据层：登录后获取权限码/策略，前端缓存并订阅变更
路由权限：守卫过滤菜单和路由，无权限跳转或隐藏
组件权限：高阶组件/指令控制按钮、字段渲染
数据权限：敏感字段由服务端过滤，前端兜底

需要避免的典型误区：

权限判断写死在前端
只控制菜单不控制路由按钮
前端信任后端返回的敏感数据

补充说明：

在实际落地设计一个可扩展的权限前端架构时，建议结合权限、RBAC、ABAC 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：模型、数据层等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

权限判断写死在前端
只控制菜单不控制路由按钮
前端信任后端返回的敏感数据

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

模型；数据层；路由权限；组件权限；数据权限。同时要避免权限判断写死在前端。

FB-25-CP-P-015：前端架构中的延迟决策原则如何实践

题型：综合开放题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：25 系统架构设计标签：延迟决策、演进式架构、可扩展性、架构原则 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请解释架构设计中的延迟决策原则，并举例前端如何在不牺牲质量的前提下延迟决策。

参考答案：

核心思路如下：

延迟决策：信息不足时不提前做不可逆选择
抽象稳定接口，不确定实现放到插件/适配器
例子：不确定图表库时定义图表接口，底层可替换 ECharts/D3
核心骨架定好，可变部分开放扩展
用 ADR 记录决策时机，避免无限拖延

需要避免的典型误区：

完全不做设计
把延迟决策当借口导致技术债
接口设计不稳定

补充说明：

在实际落地前端架构中的延迟决策原则如何实践时，建议结合延迟决策、演进式架构、可扩展性的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：延迟决策、抽象稳定接口，不确定实现放到插件/适配器等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

完全不做设计
把延迟决策当借口导致技术债
接口设计不稳定

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

延迟决策；抽象稳定接口，不确定实现放到插件/适配器；例子；核心骨架定好，可变部分开放扩展；用 ADR 记录决策时机，避免无限拖延。同时要避免完全不做设计。

FB-25-EN-A-016：前端如何管理软件包的依赖升级与兼容性

题型：工程化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：依赖管理、版本升级、兼容性、SemVer、lockfile 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明大型前端项目中依赖升级的策略、风险评估、影响范围控制和回滚。

参考答案：

核心思路如下：

依赖分级：核心框架、构建工具、业务库、工具库
遵循 SemVer，major 升级需评审和回归测试
渐进升级：先独立分支或试点验证，再推广
兼容性：codemod 批量迁移，破坏性变更提供 shim
回滚：lockfile 保留旧版本，构建产物版本化

需要避免的典型误区：

major 版本直接全量改
不读 changelog
升级后没有回归测试

补充说明：

在实际落地前端如何管理软件包的依赖升级与兼容性时，建议结合依赖管理、版本升级、兼容性的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：依赖分级、遵循 SemVer，major 升级需评审和回归测试等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

major 版本直接全量改
不读 changelog
升级后没有回归测试

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

依赖分级；遵循 SemVer，major 升级需评审和回归测试；渐进升级；兼容性；回滚。同时要避免major 版本直接全量改。

FB-25-SD-A-014：设计一个前端日志与审计系统

题型：系统设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：25 系统架构设计标签：日志、审计、合规、采集、脱敏 出现频率：中频 预计回答时长：8-15 分钟

题目描述：金融前端需记录用户关键操作日志用于审计。请设计采集、传输、存储和查询方案。

参考答案：

核心思路如下：

事件定义：who/when/what/result/context
采集：SDK 在关键操作点记录，本地暂存后批量加密上报
传输：HTTPS + 签名防篡改，失败重试并本地持久化
脱敏：手机号、卡号、密码不上传或哈希
存储查询：服务端不可篡改存储，支持按维度查询
合规：保留期限、不可删除、权限控制

需要避免的典型误区：

敏感信息明文上传
日志可被前端删除
缺少服务端校验签名

补充说明：

在实际落地设计一个前端日志与审计系统时，建议结合日志、审计、合规的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：事件定义、采集等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

敏感信息明文上传
日志可被前端删除
缺少服务端校验签名

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

金融前端需记录用户关键操作日志用于审计。事件定义；采集；传输；脱敏；存储查询；合规。同时要避免敏感信息明文上传。

FB-25-CO-R-019：什么是反脆弱前端架构

题型：概念题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：25 系统架构设计标签：反脆弱、韧性、故障、自愈、混沌工程 出现频率：低频 预计回答时长：8-15 分钟

题目描述：请解释前端架构中的反脆弱理念，并给出让系统在故障中更强韧的手段。

参考答案：

核心思路如下：

反脆弱：不仅抵御故障，还能从故障中学习改进
手段：错误边界、自动降级、重试熔断、缓存兜底、灰度
混沌工程：主动注入错误验证恢复能力
可观测：完整日志、指标、链路
组织：复盘、更新预案、自动化回归

需要避免的典型误区：

只追求零故障不做预案
失败时直接白屏
混沌实验在生产无控制执行

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：反脆弱、手段等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只追求零故障不做预案
失败时直接白屏
混沌实验在生产无控制执行

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

反脆弱；手段；混沌工程；可观测；组织。同时要避免只追求零故障不做预案。

系统架构设计面试题 ​

目录 ​

基础题（16 道） ​

FB-25-CO-B-001：MVC、MVVM、MVP、MVI 四种架构模式有什么区别？分别对应哪些前端框架？ ​

FB-25-CO-B-002：什么是 BFF（Backend for Frontend）？它解决了什么问题？ ​

FB-25-EN-B-003：Monorepo 是什么？与 Multirepo 相比有什么优劣？ ​

FB-25-CO-B-004：前端应用拆分有哪些常见策略？ ​

FB-25-CO-B-005：技术选型的一般流程和关键维度有哪些？ ​

FB-25-CO-B-006：什么是 ADR（Architecture Decision Record）？为什么要写 ADR？ ​

FB-25-CO-B-007：可维护性、可扩展性、可测试性在架构中分别指什么？ ​

FB-25-CO-B-008：什么是事件驱动架构？前端有哪些典型应用场景？ ​

FB-25-CO-B-009：分层架构是什么？前端项目常见的分层方式有哪些？ ​

FB-25-CO-B-010：什么是接口契约？前端如何利用契约进行协作与 Mock？ ​

FB-25-CO-B-011：什么是依赖注入（DI）和控制反转（IoC）？前端有哪些应用？ ​

FB-25-CO-B-012：什么是防腐层（Anti-Corruption Layer）？前端为什么需要它？ ​

FB-25-CO-B-013：API 版本管理有哪些常见策略？前端应如何配合？ ​

FB-25-CO-B-014：集中式状态管理与局部状态管理各适用于什么场景？ ​

FB-25-EN-B-015：如何分析前端构建产物并制定优化策略？ ​

FB-25-CO-B-016：什么是渐进式增强与优雅降级？前端如何实践？ ​

进阶题（17 道） ​

FB-25-SC-A-001：你负责一个大型中后台系统，如何进行模块拆分和分层？ ​

FB-25-SD-A-002：设计一个支持多终端接入的 BFF 层 ​

FB-25-CO-A-003：DDD（领域驱动设计）中的核心概念如何映射到前端架构？ ​

FB-25-EN-A-004：Monorepo 中如何设计包依赖关系、版本策略和发布流程？ ​

FB-25-CP-A-005：如何评估一个前端架构的可扩展性？ ​

FB-25-PE-A-006：从架构视角看，性能优化应该如何系统化思考？ ​

FB-25-SE-A-007：从架构视角看，前端安全应该如何设计？ ​

FB-25-CO-A-008：微前端有哪些实现方式？各自的优缺点是什么？ ​

FB-25-SC-A-009：设计一个前端配置中心（Feature Flag）系统 ​

FB-25-SC-A-010：设计一个前端埋点与监控 SDK 架构 ​

FB-25-SC-A-011：如何设计一个支持多租户的前端应用？ ​

FB-25-SD-A-012：设计一个前端实时协同编辑系统的架构 ​

FB-25-CO-A-013：模块化、组件化、服务化之间有什么区别与联系？ ​

FB-25-EN-A-014：前端如何实现自动化回归与架构守护？ ​

FB-25-CP-A-015：如何处理遗留系统的渐进式重构？ ​

FB-25-PE-A-016：从架构角度设计一个首屏加载优化方案 ​

FB-25-SE-A-017：从架构角度看，前端供应链安全应该如何设计？ ​

深入题（16 道） ​

FB-25-SD-P-001：设计一个低代码/搭建平台的前端架构 ​

FB-25-SC-P-002：设计一个 SDUI（Server-Driven UI）系统 ​

FB-25-CO-P-003：整洁架构（Clean Architecture）和六边形架构（Hexagonal Architecture）如何在前端落地？ ​

FB-25-CP-P-004：你所在团队要引入一个新的前端框架或工具链，请描述完整的决策过程 ​

FB-25-SC-P-005：设计一个插件化的前端应用，支持第三方扩展 ​

FB-25-CO-P-006：CQRS 和事件溯源（Event Sourcing）在前端有哪些应用场景？ ​

FB-25-EN-P-007：描述一个前端架构从单体应用到微前端再到模块化架构的演进过程 ​

FB-25-SD-P-008：设计一个金融级前端安全收银台架构 ​

FB-25-SC-P-009：设计一个支持百万级数据的表格前端架构 ​

FB-25-SC-P-010：设计一个前端国际化架构 ​

FB-25-SC-P-011：设计一个前端权限架构（RBAC/ABAC） ​

FB-25-CO-P-012：什么是数据一致性？前端如何保证最终一致性？ ​

FB-25-CO-P-013：什么是无服务器/边缘渲染架构？前端如何落地？ ​

FB-25-CP-P-014：如何做技术债管理与架构演进路线图？ ​

FB-25-EN-P-015：Monorepo 中的构建性能优化与远程缓存架构 ​

FB-25-SS-P-016：如何设计并落地前端技术委员会机制？ ​

架构题（71 道） ​

FB-25-SD-R-001：设计一个组织级前端架构治理体系 ​

FB-25-CP-R-002：如何在大型组织中平衡前端技术栈的统一与团队的差异化需求？ ​

FB-25-SC-R-003：设计一个大型电商活动搭建平台的前端架构 ​

FB-25-CO-R-004：架构评审应该关注哪些方面？ ​

FB-25-SS-R-005：如何推动一个重大技术架构升级在多个业务线落地？ ​

FB-25-CP-R-006：在复杂系统架构设计中，如何做权衡与取舍？ ​

FB-25-SD-R-007：设计一个跨团队共享的前端能力平台 ​

FB-25-SD-R-008：设计一个全球化多端统一前端架构 ​

FB-25-SD-R-009：设计一个前端智能化研发平台架构 ​

FB-25-SD-R-010：设计一个高可用的大促前端保障体系 ​

FB-25-SC-R-011：设计一个跨团队协作的组件共建与治理体系 ​

FB-25-CP-R-012：如何在业务快速迭代中保持架构质量？ ​

FB-25-CP-R-013：如何评估与引入新兴技术（如 AI 编码、WebAssembly）到生产？ ​

FB-25-SS-R-014：如何推动组织级前端工程文化变革？ ​

FB-25-CO-R-015：架构师如何进行风险建模与失效模式分析？ ​

FB-25-CO-R-016：什么是演进式架构？如何设计可演进的系统？ ​

FB-25-CO-A-014：什么是前端架构？它和框架有什么关系？ ​

FB-25-CP-A-016：简述 MVC、MVVM、MVP 的区别，并举例前端中的应用。 ​

FB-25-CO-A-015：为什么前端需要 BFF？直接调用后端微服务有什么问题？ ​

FB-25-CO-A-016：什么是 DDD？前端如何借鉴 DDD 思想？ ​

FB-25-CO-A-017：解释单一职责原则（SRP）在前端组件设计中的应用。 ​

FB-25-CO-A-018：什么是依赖倒置原则？举一个前端代码示例。 ​

FB-25-CO-A-019：你如何理解“康威定律”？它对前端架构有什么影响？ ​

FB-25-CO-A-020：分层架构中，UI 层、业务逻辑层、数据访问层各自应该做什么？ ​

二、高级题 ​

系统架构设计面试题

目录

基础题（16 道）

FB-25-CO-B-001：MVC、MVVM、MVP、MVI 四种架构模式有什么区别？分别对应哪些前端框架？

FB-25-CO-B-002：什么是 BFF（Backend for Frontend）？它解决了什么问题？

FB-25-EN-B-003：Monorepo 是什么？与 Multirepo 相比有什么优劣？

FB-25-CO-B-004：前端应用拆分有哪些常见策略？

FB-25-CO-B-005：技术选型的一般流程和关键维度有哪些？

FB-25-CO-B-006：什么是 ADR（Architecture Decision Record）？为什么要写 ADR？

FB-25-CO-B-007：可维护性、可扩展性、可测试性在架构中分别指什么？

FB-25-CO-B-008：什么是事件驱动架构？前端有哪些典型应用场景？

FB-25-CO-B-009：分层架构是什么？前端项目常见的分层方式有哪些？

FB-25-CO-B-010：什么是接口契约？前端如何利用契约进行协作与 Mock？

FB-25-CO-B-011：什么是依赖注入（DI）和控制反转（IoC）？前端有哪些应用？

FB-25-CO-B-012：什么是防腐层（Anti-Corruption Layer）？前端为什么需要它？

FB-25-CO-B-013：API 版本管理有哪些常见策略？前端应如何配合？

FB-25-CO-B-014：集中式状态管理与局部状态管理各适用于什么场景？

FB-25-EN-B-015：如何分析前端构建产物并制定优化策略？

FB-25-CO-B-016：什么是渐进式增强与优雅降级？前端如何实践？

进阶题（17 道）

FB-25-SC-A-001：你负责一个大型中后台系统，如何进行模块拆分和分层？

FB-25-SD-A-002：设计一个支持多终端接入的 BFF 层

FB-25-CO-A-003：DDD（领域驱动设计）中的核心概念如何映射到前端架构？

FB-25-EN-A-004：Monorepo 中如何设计包依赖关系、版本策略和发布流程？

FB-25-CP-A-005：如何评估一个前端架构的可扩展性？

FB-25-PE-A-006：从架构视角看，性能优化应该如何系统化思考？

FB-25-SE-A-007：从架构视角看，前端安全应该如何设计？

FB-25-CO-A-008：微前端有哪些实现方式？各自的优缺点是什么？

FB-25-SC-A-009：设计一个前端配置中心（Feature Flag）系统

FB-25-SC-A-010：设计一个前端埋点与监控 SDK 架构

FB-25-SC-A-011：如何设计一个支持多租户的前端应用？

FB-25-SD-A-012：设计一个前端实时协同编辑系统的架构

FB-25-CO-A-013：模块化、组件化、服务化之间有什么区别与联系？

FB-25-EN-A-014：前端如何实现自动化回归与架构守护？

FB-25-CP-A-015：如何处理遗留系统的渐进式重构？

FB-25-PE-A-016：从架构角度设计一个首屏加载优化方案

FB-25-SE-A-017：从架构角度看，前端供应链安全应该如何设计？

深入题（16 道）

FB-25-SD-P-001：设计一个低代码/搭建平台的前端架构

FB-25-SC-P-002：设计一个 SDUI（Server-Driven UI）系统

FB-25-CO-P-003：整洁架构（Clean Architecture）和六边形架构（Hexagonal Architecture）如何在前端落地？

FB-25-CP-P-004：你所在团队要引入一个新的前端框架或工具链，请描述完整的决策过程

FB-25-SC-P-005：设计一个插件化的前端应用，支持第三方扩展

FB-25-CO-P-006：CQRS 和事件溯源（Event Sourcing）在前端有哪些应用场景？

FB-25-EN-P-007：描述一个前端架构从单体应用到微前端再到模块化架构的演进过程

FB-25-SD-P-008：设计一个金融级前端安全收银台架构

FB-25-SC-P-009：设计一个支持百万级数据的表格前端架构

FB-25-SC-P-010：设计一个前端国际化架构

FB-25-SC-P-011：设计一个前端权限架构（RBAC/ABAC）

FB-25-CO-P-012：什么是数据一致性？前端如何保证最终一致性？

FB-25-CO-P-013：什么是无服务器/边缘渲染架构？前端如何落地？

FB-25-CP-P-014：如何做技术债管理与架构演进路线图？

FB-25-EN-P-015：Monorepo 中的构建性能优化与远程缓存架构

FB-25-SS-P-016：如何设计并落地前端技术委员会机制？

架构题（71 道）

FB-25-SD-R-001：设计一个组织级前端架构治理体系

FB-25-CP-R-002：如何在大型组织中平衡前端技术栈的统一与团队的差异化需求？

FB-25-SC-R-003：设计一个大型电商活动搭建平台的前端架构

FB-25-CO-R-004：架构评审应该关注哪些方面？

FB-25-SS-R-005：如何推动一个重大技术架构升级在多个业务线落地？

FB-25-CP-R-006：在复杂系统架构设计中，如何做权衡与取舍？

FB-25-SD-R-007：设计一个跨团队共享的前端能力平台

FB-25-SD-R-008：设计一个全球化多端统一前端架构

FB-25-SD-R-009：设计一个前端智能化研发平台架构

FB-25-SD-R-010：设计一个高可用的大促前端保障体系

FB-25-SC-R-011：设计一个跨团队协作的组件共建与治理体系

FB-25-CP-R-012：如何在业务快速迭代中保持架构质量？

FB-25-CP-R-013：如何评估与引入新兴技术（如 AI 编码、WebAssembly）到生产？

FB-25-SS-R-014：如何推动组织级前端工程文化变革？

FB-25-CO-R-015：架构师如何进行风险建模与失效模式分析？

FB-25-CO-R-016：什么是演进式架构？如何设计可演进的系统？

FB-25-CO-A-014：什么是前端架构？它和框架有什么关系？

FB-25-CP-A-016：简述 MVC、MVVM、MVP 的区别，并举例前端中的应用。

FB-25-CO-A-015：为什么前端需要 BFF？直接调用后端微服务有什么问题？

FB-25-CO-A-016：什么是 DDD？前端如何借鉴 DDD 思想？

FB-25-CO-A-017：解释单一职责原则（SRP）在前端组件设计中的应用。

FB-25-CO-A-018：什么是依赖倒置原则？举一个前端代码示例。

FB-25-CO-A-019：你如何理解“康威定律”？它对前端架构有什么影响？

FB-25-CO-A-020：分层架构中，UI 层、业务逻辑层、数据访问层各自应该做什么？

二、高级题