企业官网建设流程全解析

前端系统设计面试中如何展现面试官评分看重的信号（需求探索、架构、权衡）？

【免费下载链接】front-end-interview-handbookFront End interview preparation materials for busy engineers (updated for 2026)项目地址: https://gitcode.com/GitHub_Trending/fr/front-end-interview-handbook

前端系统设计面试是开放式的：面试官给你一个模糊的问题（比如"Design Facebook"），你和他协作给出一个可行的设计。仓库中的 Front End System Design Playbook 明确指出：系统设计成绩直接决定 hire 结果和定级——对高级别候选人，表现差的系统设计轮几乎必然导致整体拒绝。这篇文章的目标只有一个：教你在 30–60 分钟的面试里，把面试官真正打分的三类信号——需求探索、架构、权衡——通过可见的行为展现出来。

前提：评分基于"被观察到的信号"，不是你的内心活动

评估标准文档 里有一条最关键的规则：

面试官评分的是你展现出来的行为信号。如果你思考了一个权衡但从未说出来，那么在评估意义上它没有发生过。

这句话决定整场面试的打法：每个决策和考虑都要通过口述和图表达出来。包括"为什么排除掉某个明显很差的方案"——大声否定一个非选项也算权衡推理。后文所有步骤都围绕这一点展开。

先把评估维度对应到 RADIO 结构

Playbook 给出的答题框架是RADIO：Requirements exploration（需求探索）、Architecture / high-level design（架构/高层设计）、Data model（数据模型）、Interface definition（接口定义）、Optimizations and deep dive（优化与深入）。每个阶段有建议的时间占比（框架全文）：

评估维度与 RADIO 阶段的映射关系（来自 evaluation-axes 的汇总表）：

用法：面试开始前在（虚拟）白板上写下 "RADIO"，过程中随时对照，确保每个该出信号的维度都有对应的呈现机会。RADIO 不是必须线性执行的固定流程，文档明确建议当回跳（backtrack）——例如架构阶段发现某个需求意味着初始数据模型不成立时，应立刻回去修订数据模型。

需求探索（R）：如何展现"Problem exploration"信号

这一阶段建议不超过会话的 10%，但它是其余所有阶段的地基——没有明确需求就谈不上设计。框架文档给的姿态是：把面试官当作你合作的产品经理，主动提问，挖出模糊性。

文档列出的澄清问题（可直接作为自己的问题清单）：

1. 应该聚焦哪些主要用例？例如 "Design Facebook"，答案在面试官心里，你要靠提问找到它。文档的例子：Facebook 的核心是 news feed、feed 分页和创建新帖子；YouTube 是视频观看体验。按产品类型找核心特征的列表见 题目类型文档。不澄清就直接开讲，最好情况是被拉回来并在面试官心里记一笔，最坏情况是浪费几分钟讲一个无关紧要的主题。
2. 功能需求和非功能需求是什么？功能需求是产品不能缺少的基本能力；非功能需求是性能、可扩展性、体验等改进项。获取答案的优先方式是：主动列出你认为的需求，请面试官反馈和对齐；直接问也可以，但面试官通常希望你自己定义。
3. 哪些是核心功能，哪些是 good-to-have？先就核心功能达成设计共识，再谈附加功能。
4. 其他可能的问题：支持哪些设备/平台（desktop/tablet/mobile）？主要用户是谁？是否需要离线使用？性能要求是什么？

判断这一步完成的标准：文档建议把达成共识的需求写下来，在后续整场面试中反复引用，确保最终设计覆盖了每一条。

架构（A）：如何展现"Architecture"信号

建议占 20% 的会话。核心任务是识别客户端关键组件、它们如何交互，并用图表达——每个组件画一个矩形，用带数据标签的箭头连接。文档强调前端系统设计评估的是客户端结构和 API 边界，服务端应视为黑盒（除非题目另有要求）：

• Server：视为黑盒，假设它通过 HTTP / GraphQL / WebSockets 暴露 API。
• View layer（视图层）：用户看到和交互的部分，含子视图和本地状态；负责展示和局部交互状态，跨视图共享的数据应放在 store 层。
• Store/model layer（存储层）：应用数据和派生状态所在，管理用户资料、认证、布局状态（如侧边栏是否打开）等跨切面数据。
• Data access layer（数据访问层）：处理请求、缓存和错误管理，让客户端不直接耦合数据来源——将来引入离线存储和后台同步时，受影响的只有这一层。

画完图之后要口头描述每个组件的职责，这一步本身就是"Architecture"信号的载体：把问题拆成粒度合适的小部件、明确各组件职责、说明组件如何协作。

文档以 News Feed 为例给出了组件职责示范：

• Server：暴露 HTTP API 拉取 feed 帖子和创建新帖子
• Store：存放整个应用需要的数据，feed 场景下多为来自服务端、视图层需要展示的数据
• Data access layer：向服务端发请求，把取到的数据交给 store，同时充当网络数据缓存
• Feed UI：feed 帖子列表和发帖 UI；含Feed post（展示帖子数据、点赞/分享/评论按钮）和Post composer（发帖 UI）

两个边界条件：小产品（单页或单个 UI 组件）允许数据全部放在组件本地状态里，不必套用四层；讨论保持在"设计"层面，除非面试官追问，不需要指定具体框架或库。

数据模型（D）与接口定义（I）：让架构可落地

数据模型占 ~10%。文档把客户端数据按来源分类，列表时标明每个字段的类型和来源：

• Server-originated：来自服务端、多端共享（用户资料、feed 帖子、评论）。
• Client-originated，再分两类：
  • 要持久化的：需要发回服务端入库（表单输入、个人设置）。
  • Ephemeral（临时）：浏览器标签页关闭后丢失也无妨（表单校验状态、当前导航 tab、分区是否展开）。

文档的 News Feed 示例数据模型（文档示例）：

接口定义占 ~20%。文档指出所有 API 都有三要素：名称/功能（HTTP path 或 JS 函数/事件名）、参数（GET query 和 POST 参数，或函数/事件参数）、返回值（HTTP 响应，通常 JSON；或可选的函数返回值）。News Feed 场景下服务端提供 RESTful HTTP API（文档示例）：

{ "size": 10, "cursor": "=dXNlcjpXMDdRQ1JQQTQ" }

请求GET /feed的响应：

{ "pagination": { "size": 10, "next_cursor": "=dXNlcjpVMEc5V0ZYTlo" }, "results": [ { "id": "123", "author": { "id": "456", "name": "John Doe" }, "content": "Hello world", "image": "https://www.example.com/feed-images.jpg", "reactions": { "likes": 20, "haha": 15 }, "created_time": 1620639583 } ] }

以上是文档给出的示例值，练习时用自己的实体字段替换即可，重点不是照抄。浏览器内的组件间通信，面试中最常见的是中心 store 的 action 及其 payload（如 Flux/Redux 的 action 对象、Zustand/Pinia 的 setter），口述"哪个 action 改变数据模型的哪些字段"时，就是在同时打 Data model 和 Interface 两个维度的分。

权衡（Exploration & tradeoffs）：被明确当作定级信号

评估文档对权衡的描述是全文信号密度最高的一段：

• 对当前问题给出多种可行方案，并解释各自的优缺点。注意这里的"问题"不一定是大题目本身——解题过程中每个小决策（分页方案、状态放哪里、通信协议选 HTTP/WebSocket/SSE）都有多个可选方案，每个都要摆出来。
• 结合题目上下文说明每个方案的适用性，并给出推荐。
• 不要坚持只有一个解。"Even if the other solutions are clearly and obviously bad, do still mention them and briefly explain why they are bad."——把被拒绝的备选方案说出口，本身就是更强的定级信号。

具体做法：对每个关键决策，说出两三个选项 + 各自利弊 + 在本题上下文下的推荐理由。例如通信机制，文档列出的候选有 HTTP（无状态、最常见）、WebSockets（持久双向通道，适合聊天/协作编辑）、Server-Sent Events（单向推送，适合通知/行情流）、Long polling、GraphQL、WebRTC，并指出前端系统设计面试通常只需要掌握 HTTP、WebSockets 和 SSE 即可——你口述"为什么本题选 SSE 而不是 WebSocket"就是在展现这个信号。

优化与深入（O）占 ~40%，是权衡信号的主战场，但要按文档的两条指引分配时间：

1. 聚焦产品独特/重要区域。电商重点讲 SEO 和性能；协作编辑重点讲并发修改与冲突解决。
2. 展示你的强项，但必须与产品相关，不要为了展示知识开跑题讨论。

同时文档明确列出了不该花时间的话题，这些是常见失分点：框架之争（React vs Vue vs Angular）、CSS 框架选择、与问题无关的通用性能建议（压缩、缓存）、日志/监控等辅助设施、CI/CD 和 DevOps 细节、构建工具对比（webpack vs Vite）。例外只有一种：该选择会实质改变架构权衡时才提，例如 SEO 导向的内容站可以提 SSR/SSG。

用常见错误清单做最终自检

常见错误文档 列出的每一项都对应一个信号的缺失，可以当面试后的自检表：

• 拿到题就立刻开答——没有先提问和收集需求。"把错误的问题答得很好，比把正确的问题答得差更糟。"
• 无结构地漫谈——用 RADIO 框架，开场把 RADIO 写在白板上，结束时确认每个部分都覆盖到了。
• 坚持只有一个/最好的解——面试官想听到的是"识别出与问题匹配的、权衡正确的方案"，以及你为什么放弃其他方案。
• 全程沉默——系统设计是协作练习，像对待同事一样和面试官讨论、抛问题、交换想法。
• 钻牛角尖——先给出初始高层设计再展开；不确定是否该深入某组件时，直接问面试官。
• 抛出解释不了的术语——用了 "Virtual DOM"、"Partial Hydration" 这类词就要能经受追问，答不上来的伤害比不提更大。

练习时的验证方式

没有代码可运行，验证靠两个文档给出的对照手段：

1. 覆盖度检查：会话结束后拿 cheatsheet 里的 6 条评估维度（problem exploration / architecture / technical proficiency / exploration & tradeoffs / product & UX sense / communication & collaboration）逐条问自己：这条信号我在哪个环节、用什么话术或图展现了？对照上文"评估维度 × RADIO"映射表，能指到具体阶段的才算数。
2. 时间预算检查：对照 ~10/20/10/20/40 的时长占比，确认需求探索没有吃掉架构时间，优化阶段没有散落在无关话题上。

限制说明：RADIO 框架不适用于过度具体、几乎不需要架构的题（文档的例子是"实现 Slack 的 mention 功能"）；UI 组件类题目（autocomplete、modal、dropdown 等）另有侧重——先拆子组件、定义对外 props API、描述内部状态，再深入性能、可访问性、安全性，详见 UI 组件 API 设计原则 与 题目类型文档。仓库内的 cheatsheet 是这几篇文档的单页汇总，适合面试前快速过一遍。

【免费下载链接】front-end-interview-handbookFront End interview preparation materials for busy engineers (updated for 2026)项目地址: https://gitcode.com/GitHub_Trending/fr/front-end-interview-handbook