frontend-architecture git:20260920.a4843f5A

Immutable. This exact content is served forever at /api/v1/blob/1e8d484c419bb5c9.

---
name: frontend-architecture
description: 前端架构深挖：状态与数据流、服务端组件、BFF、契约与类型共享、微前端、设计系统、测试。
keywords: [前端架构, 状态管理, 数据流, server components, rsc, 数据获取, bff, 契约, openapi, 类型共享, monorepo, 微前端, 设计系统, 组件库, 前端测试, 可访问性, a11y, 国际化]
layer: detail
domains: [frontend]
---

## 面试官在意什么

这本是前端往工程与架构方向的深挖：一个多人维护、多端复用的前端系统怎么组织。面试官看的是取舍能不能落到团队规模：BFF 该不该建、状态放哪层、类型怎么共享、微前端还是 monorepo、组件库怎么升级不 break 业务。2026 年新增的追问是服务端组件把数据获取移到服务端后，客户端状态管理还剩什么、缓存与失效谁负责。

## 项目 / 实习怎么深挖

简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 project-deep-dive。

- 简历出现状态管理方案 → 追为什么选它、服务器状态与 UI 状态怎么分、URL 是不是状态源、出过什么状态不一致
- 简历出现 Server Components / Actions → 追哪些组件在服务端、数据获取与缓存怎么做、客户端状态还剩什么
- 简历出现 BFF → 追聚合了几个下游、超时熔断、最慢接口、为什么不让前端直接调
- 简历出现 monorepo / 共享类型 / 微前端 → 追共享了什么、一次改动影响面怎么控、构建时间、隔离怎么做、比另一种方案多解决了什么
- 简历出现组件库 / 设计系统 → 追按需加载、主题定制、可访问性、版本升级怎么不 break
- 简历出现前端测试 → 追测什么层、覆盖率数字、flaky 怎么治、一次靠测试拦下的问题

## 常见失守与危险信号

- 状态管理与数据流：所有状态一律扔进全局 store；分不清服务器状态和 UI 状态；没意识到 URL 也是状态源
- 服务端组件与数据获取：认为 RSC 就是 SSR；不知道服务端组件不能用 hooks；缓存与失效说不清谁负责
- BFF 与数据聚合层：把 BFF 当万能层塞业务逻辑；下游多个接口串行 await 却不知道
- 前后端契约与类型共享：接口靠口头约定；把后端实体直接暴露给前端；monorepo 就是"放一个仓库"
- 微前端与 monorepo：为了"独立部署"上微前端却没有团队边界；样式与全局变量隔离没做
- 设计系统与组件库：按需加载靠运气；主题靠覆盖样式；升级 break 业务
- 测试策略：只有单测或只有 E2E；flaky 靠重跑；不知道测什么层
- 可访问性与国际化：认为可访问性就是"给图片加 alt"；用 div 做按钮；不知道 Intl API

## 常考主题清单

只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 JD 与这份简历定，不是配额。

### 状态管理与数据流（框架无关）
- 阶梯：为什么要把状态从组件里抽出来 → 单向数据流、不可变更新、派生状态与缓存的关系 → 页面上同一份数据在多处不一致（列表与详情、缓存与服务器）怎么定位与设计（服务器状态与客户端状态分开）→ 全局 store、URL 状态、服务端缓存库三者各管什么，过度全局化的代价
- 答实的标志：区分 server state / client state / URL state；提到请求去重、缓存失效、乐观更新；能说出选择性订阅避免无关重渲染

### 可访问性与国际化
- 阶梯：语义化标签、alt、label 的作用 → ARIA 的角色与状态、键盘可操作、焦点管理 → 自定义下拉/弹窗在读屏软件里不可用怎么修，焦点陷阱怎么做 → 无障碍改造的投入与合规要求（出海、政企项目）之间的取舍，国际化时文本长度、RTL、日期数字格式的坑
- 答实的标志：焦点管理、Esc 关闭、aria-modal、背景 inert；提到 prefers-reduced-motion；国际化用 ICU 消息格式而不是字符串拼接

### BFF 与数据聚合层
- 阶梯：BFF 是什么、和网关有什么区别 → 聚合、裁剪、缓存、鉴权放 BFF 哪些合适哪些不合适 → BFF 变成"胖中间层"、逻辑重复、一个页面改动要动三层，怎么治理 → 多端（Web/小程序/App）一套 BFF 还是各自一套，团队边界怎么划
- 答实的标志：并行请求与超时熔断；按端拆 BFF 的边界理由；用 trace 看串行/并行；对 Node 事件循环延迟有监控概念

### 前后端契约与类型共享
- 阶梯：接口文档谁写、什么时候定 → OpenAPI/TypeScript 类型共享、mock 与契约测试如何让两端并行；GraphQL 的 N+1、over-fetching 解决了什么又带来了什么 → 上线后前端发现字段语义和文档不一致怎么防止再发生；共享包一改全站构建、版本地狱、循环依赖怎么治 → 契约先行的成本与灵活性按团队规模取舍；哪些该共享哪些坚决不共享
- 答实的标志：schema（zod/OpenAPI）为唯一事实来源并生成类型；版本、默认值、字段废弃策略；对 GraphQL 有明确的适用场景判断；兼容期字段可选

### 服务端组件与数据获取
- 阶梯：服务端组件解决什么（数据获取靠近数据、少发 JS）、代价是什么 → 服务端组件与客户端组件的边界怎么划、hooks 与交互放哪 → 数据获取的缓存、失效、Actions 的 pending 与错误状态怎么管 → 什么应用值得上、迁移成本、和纯 CSR 的取舍
- 答实的标志：能说出服务端与客户端组件的边界依据；知道缓存与失效由谁负责；有迁移或对比的判断

### 微前端与 monorepo
- 阶梯：什么问题需要微前端（团队边界、独立发布）、什么问题 monorepo 就够 → 样式与全局变量隔离、公共依赖共享、路由与通信各怎么做 → 一次改动影响面怎么控、构建时间怎么治（缓存、affected 检测）、循环依赖怎么查 → 两种方案的长期维护成本
- 答实的标志：有团队规模对应的方案判断；隔离与共享有具体手段；有构建时间或影响面的数字

### 设计系统与组件库
- 阶梯：组件库解决什么、什么时候不该自建 → 按需加载与 tree shaking 怎么保证、主题定制方案、token 体系 → 版本升级怎么不 break 业务（兼容期、codemod、变更日志）→ 可访问性做到什么程度；组件库与业务的边界
- 答实的标志：有按需加载的验证方式；升级有兼容策略；知道组件库的维护成本

### 测试策略
- 阶梯：单测、组件测试、E2E 各测什么、比例怎么定 → 测什么不测什么：逻辑、交互、视觉回归 → flaky 测试的成因（时序、网络、环境）与治理 → 测试在 CI 里的时长与收益；一次靠测试拦下的问题
- 答实的标志：有分层与比例；flaky 有治理手段；能说出测试拦下的具体问题