开发者体验与工程效能 面试题

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

目录

• 基础题
• 进阶题
• 深入题
• 架构题

---

基础题（8 道）

FB-21-CO-B-001：什么是开发者体验（DX），它和用户体验（UX）有什么关系？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、开发者体验、效能度量 出现频率：高频 预计回答时长：2-3 分钟

题目描述： 请解释开发者体验（Developer Experience，DX）的含义，并说明它与用户体验（UX）之间的关系。

参考答案：

核心要点：开发者体验是开发者在完成软件交付过程中，与工具、流程、文档、平台交互时所产生的整体感受；好的 DX 能直接提升交付效率与质量，并最终反哺用户体验。

详细解释：

1. DX 的范畴

   • 工具链：编辑器、脚手架、构建工具、调试器、CLI。
   • 流程：Git 工作流、Code Review、CI/CD、发布上线。
   • 知识：文档、示例、API 设计、错误信息。
   • 协作：需求沟通、反馈渠道、内部支持。

2. DX 与 UX 的关系

   • DX 是 UX 的“上游”：开发者使用的内部工具、框架、组件库越顺手，产出越稳定、迭代越快，最终产品体验越好。
   • 二者设计原则相通：都关注可用性、可学习性、效率、容错性。
   • 差异：UX 面向终端用户，关注情感与任务完成；DX 面向工程师，关注自动化、反馈速度和可调试性。

3. 简单示例

   • 一个组件库如果文档完整、类型完善、错误提示清晰，开发者集成时少踩坑，上线后 Bug 更少，用户满意度更高。

最佳实践：

• 把“减少开发者等待时间”作为核心指标（构建、测试、部署）。
• 错误信息要包含上下文、修复建议和文档链接。
• 定期收集开发者反馈（NPS、痛点调研）并量化。

评分维度：

• 概念准确性（40%）：能清晰定义 DX 并指出工具、流程、文档等维度
• 关系阐述（35%）：能说明 DX 与 UX 的上下游关系及相通性
• 举例能力（25%）：能用具体工具或组件库举例

常见错误：

• 把 DX 简单等同于工具好用，忽略流程和文化
• 认为 DX 只影响开发效率，与最终用户无关
• 混淆 DX 与 DevOps、工程化概念边界

延伸追问：

• 你过去做过哪些提升 DX 的具体措施？效果如何度量？
• 如果业务方只关注功能上线，怎么说服他们投入 DX？

相关题目：

• FB-21-CO-A-016 开发者反馈循环
• FB-21-CP-P-021 DORA 与 SPACE

参考资源：

• Martin Fowler - Developer Experience
• DX 白皮书

口头回答版：

开发者体验就是工程师在日常开发中跟工具、流程、文档、平台打交道时的整体感受。它和用户体验不是割裂的：DX 是 UX 的上游，开发者用得好，Bug 少、迭代快，最终产品体验才会好。DX 关注自动化、反馈速度和可调试性，比如构建快、报错清楚、文档齐全，都是好 DX。

---

FB-21-EN-B-002：前端脚手架通常要解决哪些问题？举例说明 create-vite 或 create-next-app 的设计目标。

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Vite、Babel、脚手架 出现频率：高频 预计回答时长：3-5 分钟

题目描述： 请说明前端脚手架的核心职责，并以 create-vite 或 create-next-app 为例，解释它如何提升开发者体验。

参考答案：

核心要点：脚手架通过“约定优于配置”的方式，把项目初始化、依赖安装、目录结构、构建配置、开发服务器等重复劳动自动化，让开发者几秒即可进入编码状态。

详细解释：

1. 脚手架解决的 5 类问题

   • 初始化：创建目录、生成 package.json、安装依赖。
   • 规范：统一目录结构、代码风格、Git 提交规范。
   • 配置：预设构建工具链（Babel、TypeScript、ESLint、测试框架）。
   • 开发体验：热更新（HMR）、代理、环境变量、错误遮罩。
   • 部署：输出产物、静态资源优化、环境配置。

2. create-vite 示例

   • 通过 npm create vite@latest my-app -- --template react-ts 一键生成基于 Vite + React + TS 的项目。
   • 内置 HMR、基于 esbuild 的快速冷启动、开箱即用的 TypeScript 支持。
   • 目录结构清晰，配置极简，适合快速验证与中小型项目。

3. create-next-app 示例

   • npx create-next-app@latest 支持 App Router、Tailwind、TypeScript、ESLint 等选项。
   • 内置 SSR/SSG、路由、图片优化、API 路由，减少技术选型与集成成本。

最佳实践：

• 团队级脚手架应支持模板市场，允许业务线扩展自己的 template。
• 提供交互式 CLI 收集项目信息（名称、技术栈、是否需要 SSR）。
• 初始化后给出下一步命令提示，降低首次使用门槛。

评分维度：

• 职责覆盖（40%）：能说出初始化、规范、配置、开发、部署五类问题
• 示例分析（35%）：能结合 create-vite/create-next-app 说明设计目标
• 团队实践（25%）：能提到模板化、交互式 CLI 等扩展思路

常见错误：

• 只把脚手架理解为项目生成器，忽略持续维护与升级
• 认为越复杂越好，堆砌配置导致模板臃肿
• 忽略文档和示例，导致新手无法快速上手

延伸追问：

• 如果团队需要同时维护 React、Vue、小程序三套脚手架，如何复用核心逻辑？
• 脚手架版本升级时，如何平滑迁移存量项目？

相关题目：

• FB-21-EN-A-009 团队级项目模板设计
• FB-21-SD-R-025 可扩展的脚手架生态设计

参考资源：

• Vite 官方文档 - 快速开始
• Next.js 官方文档 - 创建项目

口头回答版：

前端脚手架主要是把创建项目、装依赖、写配置这些重复劳动自动化。比如 create-vite 一条命令就能生成 Vite + React + TS 项目，冷启动很快、HMR 很顺；create-next-app 则帮你把 SSR、路由、图片优化都配好。团队用的话，最好做成可扩展的模板，支持不同业务线，并且持续升级维护。

---

FB-21-CO-B-003：Monorepo 和 Multirepo 在开发者体验上有什么差异？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：Monorepo、pnpm、Turborepo、前端工程化 出现频率：高频 预计回答时长：3-5 分钟

题目描述： 请对比 Monorepo 与 Multirepo 在开发体验、协作效率和工具链上的主要差异。

参考答案：

核心要点：Monorepo 把多个相关项目放在单一仓库管理，便于跨包重构、原子提交和统一工具链；Multirepo 强调独立自治，适合边界清晰、需要独立发布节奏的团队。

详细解释：

维度	Monorepo	Multirepo
代码可见性	全仓库代码可见，便于复用和重构	仅能看到自己仓库，跨库改动成本高
原子提交	一次提交可改多个包，保证一致性	需要跨仓库协调 PR/MR
依赖管理	统一 node_modules、统一版本策略	各仓库独立管理，易出现版本漂移
构建/测试	可统一跑全仓库测试和 affected tasks	各仓库自行配置，CI 分散
权限控制	粒度较粗，需配合 CODEOWNERS	仓库级别权限，天然隔离
工具要求	需要 pnpm workspace / Turborepo / Nx 等	Git + npm 即可

开发者体验影响：

• Monorepo 中改一个公共组件可立刻看到所有 consumer 的影响，但仓库大时安装、构建会变慢。
• Multirepo 启动快、autonomy 高，但跨库联调、版本对齐和共享工具链成本高。

最佳实践：

• 工具链选择：pnpm workspace 做依赖管理，Turborepo / Nx 做任务调度与缓存。
• 按业务域分包，避免把所有代码都塞进一个 package。
• 用 affected 策略和 remote cache 控制 CI 成本。

评分维度：

• 概念理解（40%）：能准确解释 Monorepo/Multirepo 的定义
• 差异对比（35%）：能从代码可见性、原子提交、依赖管理、构建测试等维度对比
• 工具与取舍（25%）：能提到 pnpm、Turborepo 及适用场景

常见错误：

• 认为 Monorepo 一定优于 Multirepo，忽略组织规模与业务边界
• 把 Monorepo 简单等同于大仓库，忽略 workspace 和 task runner 的作用
• 忽略权限、安全、CI 成本等实际落地问题

延伸追问：

• 你们团队为什么选择 Monorepo？如果重新选型会怎么选？
• Monorepo 中如何防止一个包的改动导致全仓库大规模重跑 CI？

相关题目：

• FB-21-EN-A-010 pnpm workspace + Turborepo
• FB-21-SD-R-027 Monorepo 远程缓存与任务调度

参考资源：

• Monorepo.tools
• pnpm workspace 文档

口头回答版：

Monorepo 是把多个项目放到一个仓库里管，跨包重构方便，能一次提交改多个包，统一工具链；Multirepo 是每个仓库独立，权限清晰、启动快，但跨库联调和版本对齐麻烦。Monorepo 通常要配 pnpm workspace 做依赖管理，再用 Turborepo 或 Nx 跑任务和缓存，不然大了会很慢。

---

FB-21-CO-B-004：ESLint 和 Prettier 的分工是什么？为什么要在项目里同时配置？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、代码质量、ESLint、Prettier 出现频率：高频 预计回答时长：2-3 分钟

题目描述： 请说明 ESLint 与 Prettier 分别解决什么问题，并解释二者为什么不能互相替代。

参考答案：

核心要点：ESLint 负责“代码质量与潜在错误”，Prettier 负责“代码格式”；两者结合才能既保证逻辑正确，又消除风格争论。

详细解释：

维度	ESLint	Prettier
核心职责	发现潜在 Bug、限制危险 API、保证代码质量	统一代码风格（换行、引号、尾逗号等）
可配置性	极高，可自定义规则、插件	有主见，配置项有限
运行时机	本地开发、CI、pre-commit	保存时或 pre-commit
冲突点	如果 ESLint 也管格式，会与 Prettier 冲突	只关注格式

为什么同时配置：

• ESLint 无法像 Prettier 一样给出高度一致、无争议的格式化结果。
• Prettier 无法检测变量未使用、闭包泄漏、错误的使用方式。
• 同时使用时应避免规则冲突：
  • 使用 eslint-config-prettier 关闭与 Prettier 冲突的 ESLint 格式规则。
  • 使用 eslint-plugin-prettier 将 Prettier 作为 ESLint 规则运行，便于统一输出。

最佳实践：

• 在 CI 中先跑 Prettier --check，再跑 ESLint，失败即阻断。
• 结合 lint-staged 在提交前只对暂存区文件跑检查，提升速度。
• 将配置纳入脚手架模板，新员工无需关心风格。

评分维度：

• 分工清晰（50%）：能明确区分质量检查与格式统一
• 冲突处理（30%）：能提到 eslint-config-prettier / eslint-plugin-prettier
• 工程实践（20%）：能说明 CI 阻断、lint-staged 等落地方式

常见错误：

• 认为 ESLint 可以替代 Prettier，忽略格式一致性
• 同时启用 ESLint 格式规则和 Prettier 导致反复报错
• 只在本机配置，不在 CI 中强制执行

延伸追问：

• 如果团队中有人坚持用双引号、有人坚持用单引号，如何决策？
• ESLint 9 flat config 和之前的 .eslintrc 有什么区别？

相关题目：

• FB-21-EN-A-012 Git Hooks 自动化代码检查
• FB-21-EN-A-013 TypeScript compilerOptions 取舍

参考资源：

• ESLint 官方文档
• Prettier 官方文档

口头回答版：

ESLint 主要管代码质量和潜在错误，比如变量没用到、用了不安全的写法；Prettier 管代码格式，比如换行、引号、尾逗号。它们不能互相替代。一起用的时候要注意关掉 ESLint 里和 Prettier 冲突的格式规则，用 eslint-config-prettier。CI 上要先检查格式再跑 ESLint，提交前用 lint-staged 只检查改了的文件。

---

FB-21-EN-B-005：Git Hooks 最常见的两个场景是什么？简述 pre-commit 和 commit-msg 的作用。

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Git、代码质量、Git Hooks 出现频率：高频 预计回答时长：2-3 分钟

题目描述： 请说明 Git Hooks 在前端工程中的典型应用场景，并解释 pre-commit 和 commit-msg 钩子的职责。

参考答案：

核心要点：Git Hooks 是在 Git 特定生命周期自动执行的脚本，能把代码检查、格式化和提交规范强制在本地完成，避免把低级问题带到仓库或 CI。

详细解释：

1. pre-commit

   • 触发时机：git commit 执行后、提交完成前。
   • 常见用途：
     • 运行 lint-staged 对暂存区文件执行 ESLint / Prettier。
     • 运行单元测试或类型检查。
     • 若失败则阻止提交，开发者必须先修复。

2. commit-msg

   • 触发时机：提交信息编辑完成后。
   • 常见用途：
     • 校验 commit message 格式（如 Conventional Commits）。
     • 强制关联 issue 号或工作项。
     • 限制标题长度、禁止无意义描述。

其他常用钩子：

• pre-push：推送前跑更重的测试或安全检查。
• post-merge / post-checkout：自动安装依赖或清理缓存。

最佳实践：

• 用 Husky 管理钩子，lint-staged 只检查变更文件，避免全仓库扫描拖慢提交。
• 钩子失败信息要清晰，告诉开发者如何修复。
• 对于大型项目，pre-commit 只跑轻量检查，重任务放到 CI。

评分维度：

• 钩子机制（40%）：能说明 Git Hooks 是 Git 生命周期脚本
• pre-commit 作用（30%）：能说出 lint-staged、轻量检查、阻止提交
• commit-msg 作用（30%）：能说出提交信息规范校验

常见错误：

• 在 pre-commit 中跑全量测试，导致提交很慢
• 只配置 hooks 但不提供自动修复命令，增加开发者负担
• 绕过 hook 用 git commit --no-verify，长期破坏规范

延伸追问：

• Husky v9 与 v8 在配置方式上有什么不同？
• 如何在不强制所有项目改 package.json 的情况下统一团队 Git Hooks？

相关题目：

• FB-21-EN-A-012 Git Hooks 自动化代码检查
• FB-21-CO-B-004 ESLint 与 Prettier 分工

参考资源：

• Git 官方文档 - Hooks
• Husky 文档

口头回答版：

Git Hooks 是 Git 在特定时机自动执行的脚本。最常见的两个场景：pre-commit 在提交前对暂存区文件跑 lint、格式化或类型检查，失败就阻止提交；commit-msg 校验提交信息格式，比如是否符合 Conventional Commits。用 Husky 管理钩子，lint-staged 只检查改了的文件，避免提交太慢。

---

FB-21-EN-B-006：TypeScript 项目中为什么要拆分 tsconfig.json？常见拆分策略是什么？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：TypeScript、前端工程化、Monorepo、代码质量 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 请解释为什么在大型项目或 Monorepo 中通常会把 tsconfig.json 拆分为多个文件，并说明常见拆分策略。

参考答案：

核心要点：拆分 tsconfig.json 可以减少重复配置、明确编译边界、加速类型检查，并让不同子项目（应用、库、测试、脚本）拥有适合自身的编译选项。

详细解释：

1. 拆分的收益

   • 减少重复：公共选项放在 base 配置，子项目继承。
   • 明确边界：每个 package/app 只编译自己的文件，避免全仓库扫描。
   • 差异化策略：应用可开 noEmit，库需要声明文件；测试允许更宽松的类型。
   • 并行加速：配合 TypeScript project references，增量类型检查更快。

2. 常见拆分策略

   • tsconfig.base.json：公共编译选项、路径映射、严格规则。
   • tsconfig.json（应用）：extends base，配置 include、exclude、compilerOptions.jsx。
   • tsconfig.lib.json（组件库）：输出 declaration / declarationMap。
   • tsconfig.node.json（脚本/配置）：针对 Node 环境，类型为 @types/node。
   • tsconfig.test.json：包含测试文件，可能关闭 noImplicitAny。

3. 示例结构

packages/
  ui/
    tsconfig.json          # extends ../../tsconfig.base.json
    tsconfig.build.json    # 仅编译 src，输出 d.ts
  app/
    tsconfig.json
    tsconfig.node.json     # vite.config.ts 等 Node 脚本

最佳实践：

• 用 extends 继承，不要复制粘贴。
• Monorepo 中启用 composite: true 和 project references。
• 在 CI 中跑 tsc --build（或 --noEmit）做类型门禁。

评分维度：

• 拆分原因（40%）：能说出减少重复、明确边界、差异化策略、加速检查
• 策略示例（35%）：能说明 base / app / lib / test / node 等配置用途
• 工程落地（25%）：能提到 extends、composite、project references、CI 门禁

常见错误：

• 所有子项目共用一份 tsconfig，导致 include 范围过大、类型冲突
• 库配置忘记开 declaration，导致下游无类型提示
• 测试文件包含在构建配置中，拖慢编译

延伸追问：

• TypeScript project references 和普通的 tsc --build 有什么区别？
• 如何解决子项目间路径映射（paths）不一致导致的类型错误？

相关题目：

• FB-21-EN-A-013 TypeScript compilerOptions 取舍
• FB-21-SC-A-014 编辑器配置一致性

参考资源：

• TypeScript 官方文档 - tsconfig.json
• TypeScript Project References

口头回答版：

大型项目或 Monorepo 里通常会把 tsconfig 拆成 base 配置加各个子项目配置。base 里放公共的严格规则和路径映射，子项目继承后再配自己的 include、exclude 和输出选项。这样减少了重复，明确了编译边界，还能用 project references 加速类型检查。

---

FB-21-CO-B-007：本地开发环境不一致会带来哪些问题？如何初步解决？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：Docker、前端工程化、开发者体验、环境一致性 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 请说明本地开发环境不一致对团队协作和 CI 的影响，并给出至少三种解决思路。

参考答案：

核心要点：环境不一致会导致“我本地能跑”的 Bug、CI 失败、排查成本上升；统一 Node 版本、依赖管理和容器化是最常见的突破口。

详细解释：

1. 常见问题

   • Node.js 版本差异：不同特性、npm 行为、原生模块编译失败。
   • 包管理器差异：npm / yarn / pnpm 的 lock 文件、依赖树、peer dependency 处理不同。
   • 操作系统差异：路径分隔符、换行符、环境变量、文件系统大小写敏感。
   • 全局工具差异：全局安装的 CLI 版本不同，导致脚本行为不一致。
   • 数据库/服务差异：本地 mock 与线上环境不一致。

2. 三类解决思路

   • 版本锁定：
     • 用 .nvmrc / .node-version 指定 Node 版本。
     • 用 engines 字段 + engine-strict 限制。
     • 统一包管理器并提交 lock 文件。
   • 包管理器一致性：
     • 指定 packageManager 字段（corepack）。
     • 例如 "packageManager": "pnpm@8.15.0"。
   • 容器化 / Dev Container：
     • 用 Docker 或 VS Code Dev Container 把环境打包成镜像。
     • 开发者只需启动容器即可获得一致环境。

最佳实践：

• 在 README 中写清启动步骤，并提供一键脚本。
• CI 使用与本地一致的 Node 版本和包管理器。
• 对依赖升级进行灰度，先让部分成员验证。

评分维度：

• 问题识别（40%）：能列举 Node 版本、包管理器、操作系统、全局工具等差异带来的问题
• 解决方案（40%）：能说出版本锁定、统一包管理器、容器化三类方法
• 落地细节（20%）：能提到 packageManager、.nvmrc、lock 文件、CI 一致性

常见错误：

• 只强调 Node 版本，忽略包管理器和操作系统差异
• 让开发者自行安装全局工具而不做版本锁定
• lock 文件不提交或不同成员使用不同包管理器

延伸追问：

• 如果团队有人用 Windows、有人用 Mac，怎么减少路径和换行符问题？
• Dev Container 和 Docker Compose 本地开发各有什么优劣？

相关题目：

• FB-21-EN-P-019 Dev Container 配置与实践
• FB-21-EN-P-022 远程开发环境落地

参考资源：

• Node.js engines 字段
• corepack 文档

口头回答版：

本地环境不一致会导致我本地能跑、CI 却挂了这种问题，排查很费时。常见原因有 Node 版本不同、包管理器不同、操作系统差异、全局工具版本不同。解决办法：用 .nvmrc 或 engines 锁定 Node，统一包管理器并提交 lock 文件，还可以用 Dev Container 或 Docker 把环境打包。

---

FB-21-CO-B-008：什么是内部开发者文档？好的文档站点应该具备哪些特征？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：Storybook、前端工程化、开发者体验、文档 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请解释内部开发者文档在工程效能中的作用，并列出高质量内部文档站点的关键特征。

参考答案：

核心要点：内部开发者文档是团队知识的载体，能降低 onboarding 成本、减少重复询问、统一技术决策；好的文档站点应“找得到、看得懂、跟得上、能互动”。

详细解释：

1. 内部文档的价值

   • 降低新成员上手时间。
   • 统一技术规范、架构决策和最佳实践。
   • 减少“口口相传”导致的信息衰减。
   • 作为 Code Review 和培训的依据。

2. 高质量文档站点的 6 个特征

   • 可搜索：支持全文检索、标签过滤、命令面板。
   • 贴近代码：文档与代码同仓库，随版本一起更新。
   • 可验证：示例代码可运行或嵌入沙箱（Storybook、CodeSandbox）。
   • 分层清晰：快速开始、概念说明、API 参考、故障排查分开展示。
   • 所有权明确：每篇文档有负责人和最近更新日期。
   • 反馈闭环：支持一键提 issue、评论或评分。

3. 典型工具

   • VitePress / Docusaurus：技术博客和文档站点。
   • Storybook：组件库和交互示例。
   • ReadMe / Notion：轻量知识库。

最佳实践：

• 把写文档作为 PR 的一部分，缺失文档的 PR 不合并。
• 定期清理过期页面，避免“文档墓地”。
• 用日志和搜索关键词分析用户痛点，持续优化。

评分维度：

• 价值阐述（40%）：能说明文档对 onboarding、规范统一、知识传承的作用
• 特征覆盖（40%）：能列出可搜索、可验证、分层、所有权、反馈等特征
• 工具实践（20%）：能提到 VitePress、Docusaurus、Storybook 等

常见错误：

• 把文档当成一次性任务，不随代码迭代更新
• 文档只写 API 列表，缺少使用场景和示例
• 使用不可搜索的 PDF 或聊天记录作为唯一知识来源

延伸追问：

• 如何激励工程师在赶需求时仍然写文档？
• 如果文档和代码不同步，有哪些自动化手段可以发现？

相关题目：

• FB-21-SC-P-023 新成员 onboarding 流程
• FB-21-SD-R-029 组件/文档/示例一体化工具链

参考资源：

• Diátaxis 文档框架
• VitePress 官方文档

口头回答版：

内部开发者文档是团队自己的知识库，能帮新人快速上手、统一规范、减少重复问题。好的文档站点要搜得到、看得懂、跟得上代码版本，最好示例能直接运行，比如用 Storybook。文档要分快速开始、概念、API、排错几层，每篇有人负责、能反馈，并且和代码一起更新。

---

进阶题（8 道）

FB-21-EN-A-009：如何设计一个团队级项目模板（boilerplate）？需要包含哪些核心文件和配置？

题型：工程化题 / 场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Vite、Babel、脚手架、Storybook 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 如果你要为一个 20 人的前端团队设计一个项目模板，请列出必须包含的核心文件、配置和工具链，并说明取舍理由。

参考答案：

核心要点：团队级模板应覆盖“初始化即合规”的所有要素：统一技术栈、代码规范、Git 工作流、测试、CI/CD、文档和监控接入，同时保持可扩展性。

详细解释：

1. 目录与基础配置

   • package.json：固定 packageManager、scripts、engines、依赖版本。
   • .nvmrc / .node-version：锁定 Node 版本。
   • .editorconfig：统一缩进、换行符、文件编码。
   • .gitignore / .gitattributes：忽略产物、统一换行。

2. 构建与开发

   • vite.config.ts 或 webpack.config.ts：HMR、路径别名、环境变量、代理。
   • tsconfig.json（拆分 base/app/node）：严格类型、路径映射。
   • env.example：说明需要配置的环境变量。

3. 代码质量

   • .eslintrc / eslint.config.js：推荐规则 + 团队自定义。
   • .prettierrc：统一格式。
   • lint-staged.config.js + .husky/：提交前自动检查。
   • commitlint.config.js：Conventional Commits。

4. 测试

   • vitest.config.ts / jest.config.js：单元测试。
   • playwright.config.ts 或 cypress.config.ts：E2E。
   • __tests__/ 或 src/**/*.test.ts：示例测试。

5. CI/CD

   • .github/workflows/ci.yml：安装、lint、类型检查、测试、构建。
   • Dockerfile / docker-compose.yml：可选，用于部署或本地一致性。

6. 文档与示例

   • README.md：快速开始、目录说明、环境要求、脚本说明。
   • docs/：架构说明、开发规范、部署手册。
   • src/examples/：可运行的最小示例。

取舍原则：

• 不堆砌最新技术，优先选团队熟悉且生态稳定的。
• 配置能继承则继承，避免每个项目复制粘贴。
• 提供升级脚本，模板演进时存量项目可平滑迁移。

评分维度：

• 覆盖完整度（40%）：能覆盖构建、规范、测试、CI、文档等维度
• 取舍合理性（30%）：能说明为什么选这套工具链以及如何平衡复杂度
• 可维护性（30%）：能提到继承机制、升级脚本、示例和 README

常见错误：

• 把个人喜好强加到模板里，比如过新的构建工具
• 只关注初始化，不提供升级和迁移方案
• 模板过于臃肿，导致启动慢、学习成本高

延伸追问：

• 模板如何支持 SSR 和纯 CSR 两种模式？
• 如果不同业务线需要不同技术栈，模板如何设计插件机制？

相关题目：

• FB-21-EN-B-002 前端脚手架解决的问题
• FB-21-SD-R-025 可扩展的脚手架生态设计

参考资源：

• Conventional Commits
• Vite 官方文档

口头回答版：

团队级模板要让新项目一创建就合规。核心包括：统一的构建配置比如 Vite 或 Webpack、TypeScript 配置、ESLint 和 Prettier、Git Hooks、测试框架、CI 工作流、README 和文档。还要锁 Node 版本、统一包管理器。模板不要太重，优先用团队熟悉的工具，并且提供升级脚本。

---

FB-21-EN-A-010：如何利用 pnpm workspace + Turborepo 提升 Monorepo 的构建和安装速度？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：pnpm、Turborepo、Monorepo、前端工程化、性能优化 出现频率：高频 预计回答时长：5-8 分钟

题目描述： 请说明 pnpm workspace 和 Turborepo 在 Monorepo 中分别解决什么问题，并给出提升安装与构建速度的具体配置思路。

参考答案：

核心要点：pnpm workspace 解决依赖去重与 workspace 包链接，Turborepo 解决任务调度、增量构建和远程缓存；二者结合能显著降低 Monorepo 的安装和构建耗时。

详细解释：

1. pnpm workspace 的收益
   • 内容可寻址存储：同一依赖在磁盘只存一份，多个项目共享，节省空间。
   • 严格依赖结构：默认不会访问未声明的依赖，减少幽灵依赖问题。
   • pnpm-workspace.yaml 定义 workspace 包：

packages:
  - "apps/*"
  - "packages/*"

• 支持 workspace:* 协议，内部包之间引用自动链接。

2. Turborepo 的收益

   • Pipeline 定义任务依赖：build 依赖 ^build，test 依赖 build，确保执行顺序正确。
   • 本地缓存：任务输出按文件哈希缓存，未变更时直接复用。
   • 远程缓存：团队成员共享缓存，CI 也能命中。
   • Affected 模式：只运行受变更影响的包的任务。

3. 典型 turbo.json

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    },
    "lint": {}
  }
}

4. 提速手段
   • 安装：启用 node-linker=hoisted 或保持默认，配合 CI 缓存 ~/.pnpm-store。
   • 构建：精确声明 outputs 和 inputs，减少无效缓存失效。
   • 远程缓存：配置 Vercel Remote Cache 或自建 S3 cache。

最佳实践：

• 将 turbo.json 放在仓库根，所有子项目共享 pipeline。
• 用 pnpm --filter [pkg] 单独操作某个包，避免全量。
• 在 CI 中先 restore Turbo 缓存再安装依赖。

评分维度：

• pnpm workspace 理解（30%）：能说出去重、严格依赖、workspace 链接
• Turborepo 理解（35%）：能说明 pipeline、本地缓存、远程缓存、affected
• 配置与实践（35%）：能给出 turbo.json 示例和提速手段

常见错误：

• 认为 pnpm workspace 和 Turborepo 功能重复
• Turbo pipeline 中遗漏 ^build 导致任务顺序错误
• outputs 声明不完整，导致缓存命中但产物缺失

延伸追问：

• Turborepo 的 remote cache 与 Nx 的 distributed cache 有什么异同？
• 如果某个包的构建产物依赖了环境变量，如何防止缓存误命中？

相关题目：

• FB-21-CO-B-003 Monorepo 与 Multirepo 差异
• FB-21-SD-R-027 Monorepo 远程缓存与任务调度

参考资源：

• Turborepo 官方文档
• pnpm workspace 文档

口头回答版：

pnpm workspace 主要负责 Monorepo 里的依赖管理，利用内容寻址存储去重、严格依赖结构、workspace 协议链接内部包。Turborepo 负责任务调度、增量构建和缓存。配置 turbo.json 定义任务依赖，比如 build 要先等依赖包 build 完，输出 dist，这样没改动的包直接读缓存。配合远程缓存，CI 也能秒级复用。

---

FB-21-PE-A-011：大型前端项目冷启动慢，如何系统性地分析和优化构建性能？

题型：性能优化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：Webpack、Vite、性能优化、前端工程化、构建性能 出现频率：高频 预计回答时长：5-8 分钟

题目描述： 请给出分析和优化大型前端项目构建性能（冷启动和热更新）的完整思路，包含至少 3 个可落地的优化手段。

参考答案：

核心要点：构建性能优化要先度量再动手，区分“解析/转换多”、“依赖体积大”、“I/O 慢”三类瓶颈，再针对性使用工具升级、缓存、精简依赖和并行化。

详细解释：

1. 度量手段

   • Webpack：speed-measure-webpack-plugin 看各 loader/plugin 耗时。
   • Vite：DEBUG=vite:resolve vite 或 vite --profile。
   • 通用：CI 中记录 npm run build 耗时，建立趋势图。
   • 浏览器 DevTools Performance 分析 HMR 卡顿。

2. 常见瓶颈与优化

   • 依赖过多/过大：
     • 用 vite-bundle-visualizer / webpack-bundle-analyzer 分析体积。
     • 替换重型库（moment -> dayjs），按需加载（lodash-es）。
   • Loader/Plugin 慢：
     • 对大型第三方库使用 exclude / include 缩小处理范围。
     • 用 esbuild-loader 替代 babel-loader 处理 JS/TS。
     • SWC 或 esbuild 做转译。
   • 类型检查阻塞：
     • 将 tsc 从构建主流程中剥离，使用 fork-ts-checker-webpack-plugin。
     • Vite 中类型检查由 IDE 负责，构建不阻塞。
   • 缓存：
     • Webpack 持久化缓存 cache: { type: filesystem }。
     • Turborepo / Nx 远程缓存。
   • 并行化：
     • 升级构建工具到多线程/多进程实现。
     • 拆分应用为微前端或独立部署单元。

3. HMR 优化

   • 限制被监听的文件数量，排除 node_modules / 大目录。
   • 使用 Vite 等基于 ESM 的开发服务器。
   • 避免在热路径中执行全量类型检查或复杂计算。

最佳实践：

• 建立构建耗时基线，每次优化后对比。
• 先优化耗时最长的 20% 任务，通常能获得 80% 收益。
• 不要盲目升级到最新构建工具，要评估迁移成本和团队熟悉度。

评分维度：

• 度量能力（30%）：能说出至少两种构建性能分析工具或方法
• 优化手段（40%）：能覆盖依赖体积、loader、类型检查、缓存、并行化中的至少三类
• 系统性（30%）：能说明先度量再优化、建立基线、避免盲目升级

常见错误：

• 一上来就加缓存，但不分析瓶颈来源
• 把类型检查阻塞在构建主线程
• 为了优化而拆分过度，增加部署复杂度

延伸追问：

• Webpack 的 persistent cache 失效场景有哪些？
• 在 Monorepo 中，如何定位是哪个子项目拖慢了整体构建？

相关题目：

• FB-21-EN-A-010 pnpm workspace + Turborepo
• FB-21-CP-R-026 CI 反馈时间优化

参考资源：

• Webpack 构建性能指南
• Vite 性能优化

口头回答版：

构建优化要先度量。Webpack 可以用 speed-measure-webpack-plugin 看各 loader 耗时，Vite 可以开 debug。常见瓶颈有依赖太大、loader 慢、类型检查阻塞、缓存没配好。优化手段包括：分析 bundle 体积替换重型库、用 esbuild 或 SWC 替代 babel-loader、把 tsc 从构建主流程剥离、开启持久化缓存或远程缓存。先抓耗时最长的大头。

---

FB-21-EN-A-012：如何配置 Git Hooks 自动化代码检查？请给出 .lintstagedrc 和 Husky 的示例。

题型：工程化题 / 手写代码题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Git、代码质量、ESLint、Prettier 出现频率：高频 预计回答时长：5-8 分钟

题目描述： 请说明如何用 Husky + lint-staged 在提交前自动执行 Prettier 和 ESLint，并写出对应的配置文件示例。

参考答案：

核心要点：Husky 负责注册 Git Hooks，lint-staged 负责只对暂存区文件运行命令，两者结合可在不拖慢提交的前提下保证代码质量。

详细解释：

1. 安装

pnpm add -D husky lint-staged
pnpm exec husky init

2. lint-staged 配置（.lintstagedrc.json）

{
  "*.{js,jsx,ts,tsx}": [
    "eslint --fix",
    "prettier --write"
  ],
  "*.{json,md,css,scss}": [
    "prettier --write"
  ]
}

3. Husky pre-commit（.husky/pre-commit）

#!/bin/sh
pnpm exec lint-staged

Husky v9 默认生成的钩子文件内容非常简洁：

pnpm exec lint-staged

4. commit-msg 校验

#!/bin/sh
pnpm exec commitlint --edit $1

5. 关键设计点
   • 只对 staged 文件执行，避免全仓库扫描。
   • 使用 --fix / --write 自动修复能修的问题。
   • 复杂检查（全量测试、E2E）放到 CI，不阻塞本地提交。

最佳实践：

• 把 .husky/ 和 lint-staged 配置纳入版本控制。
• 提供 git commit --no-verify 的应急方案，但要事后补齐。
• 在 CI 中再次跑全量 lint，防止 hook 被绕过。

评分维度：

• 工具分工（30%）：能说明 Husky 管钩子、lint-staged 管暂存区文件
• 配置正确性（40%）：能写出 .lintstagedrc 和 pre-commit 钩子示例
• 设计取舍（30%）：能说明为什么只跑 staged、复杂任务放 CI

常见错误：

• 在 pre-commit 中跑全量单元测试或 E2E
• lint-staged 命令路径错误，导致只对部分文件生效
• 忘记把 .husky 目录提交，其他成员无法触发 hook

延伸追问：

• lint-staged 和 nano-staged 有什么区别？
• 如何处理 lint-staged 自动修复后需要重新 add 文件的问题？

相关题目：

• FB-21-CO-B-005 Git Hooks 常见场景
• FB-21-CO-B-004 ESLint 与 Prettier 分工

参考资源：

• lint-staged 官方文档
• Husky 官方文档

口头回答版：

Husky 用来注册 Git Hooks，lint-staged 只对暂存区文件跑命令。配置时 .husky/pre-commit 里执行 pnpm exec lint-staged，.lintstagedrc 里对 js/ts 文件跑 eslint --fix 和 prettier --write。关键是只检查 staged 文件，避免提交很慢；全量测试和 E2E 放 CI。

---

FB-21-EN-A-013：TypeScript 项目中 compilerOptions 的关键项如何取舍？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：TypeScript、前端工程化、代码质量 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请说明 TypeScript 配置中 strict、noImplicitAny、skipLibCheck、isolatedModules、verbatimModuleSyntax 等关键项的作用和取舍原则。

参考答案：

核心要点：TS 配置的核心矛盾是“严格性”与“迁移成本”。推荐以 strict: true 为目标，对存量项目分阶段开启；同时关闭会显著拖慢构建或破坏兼容的选项。

详细解释：

选项	作用	建议
strict	开启所有严格类型检查	新项目直接 true；存量项目分阶段开启
noImplicitAny	禁止隐式 any	必须开启，否则类型安全大打折扣
strictNullChecks	严格空值检查	强烈建议开启，能捕获大量运行时错误
skipLibCheck	跳过 .d.ts 类型检查	大型项目建议开启，显著加速编译
isolatedModules	确保每个文件可独立编译	Babel/swc/esbuild 转译时建议开启
verbatimModuleSyntax	保留 import type / export type	TS 5.0+ 推荐，避免运行时引入类型 only 模块
declaration / declarationMap	输出 .d.ts 和 sourcemap	库项目必须开启
paths	路径别名	配合构建工具 alias 使用
resolveJsonModule	允许 import json	需要时开启

取舍原则：

• 新项目：strict: true、skipLibCheck: true、isolatedModules: true。
• 存量迁移：先开 noImplicitAny 和 strictNullChecks，逐步补类型；不要一次性全仓库改完。
• 库项目：必须输出 declaration，不开 skipLibCheck 时对上游 .d.ts 严格检查可能拖慢，可权衡开启。
• 应用项目：更关注编译速度，skipLibCheck: true 通常是安全的。

最佳实践：

• 将严格规则放在 base tsconfig，子项目继承。
• 配合 @ts-expect-error 管理已知但暂时无法修复的类型问题。
• 在 CI 中跑 tsc --noEmit，防止类型回归。

评分维度：

• 关键项理解（40%）：能准确解释 strict、skipLibCheck、isolatedModules 等至少 4 个选项
• 取舍能力（35%）：能区分新项目、存量项目、库项目、应用项目的配置策略
• 工程落地（25%）：能提到分阶段开启、base 继承、CI 门禁

常见错误：

• 为了快速上线关闭所有严格检查，导致类型系统形同虚设
• 库项目不开 declaration，下游无法获得类型提示
• 一次性在全仓库开启 strict，导致大量类型错误无法消化

延伸追问：

• skipLibCheck: true 可能隐藏哪些风险？
• isolatedModules 为什么对 Babel 转译很重要？

相关题目：

• FB-21-EN-B-006 拆分 tsconfig.json
• FB-21-SC-A-014 编辑器配置一致性

参考资源：

• TypeScript Compiler Options
• TypeScript strict 模式

口头回答版：

TS 配置要平衡严格性和迁移成本。新项目建议 strict true，同时开 skipLibCheck 加速编译、isolatedModules 配合 swc/esbuild。存量项目不要一次性全开，先开 noImplicitAny 和 strictNullChecks 逐步补类型。库项目要输出 declaration。应用项目可以开 skipLibCheck 提升速度。

---

FB-21-SC-A-014：团队里不同成员使用 VS Code / WebStorm，如何保证编辑器配置和扩展一致？

题型：场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、TypeScript、开发者体验、编辑器配置 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请设计一套方案，让使用不同编辑器的团队成员都能获得一致的代码提示、格式化、类型检查和调试体验。

参考答案：

核心要点：编辑器一致性应通过“项目级配置 + 推荐扩展 + 统一 CLI”三层实现，避免把负担转移到开发者个人习惯上。

详细解释：

1. 项目级配置文件

   • .editorconfig：统一缩进、换行、编码，跨编辑器通用。
   • .vscode/settings.json：推荐 VS Code 配置，如默认格式化器、保存自动格式化、TypeScript 版本路径。
   • .vscode/extensions.json：推荐安装 ESLint、Prettier、TypeScript 相关扩展。
   • .idea/ 或 *.iml：WebStorm 项目配置，可共享部分代码风格设置。

2. 统一命令行入口

   • 不依赖编辑器插件执行 lint/format，而是提供 pnpm lint、pnpm format、pnpm typecheck。
   • CI 使用同样命令，保证结果一致。
   • 用 packageManager 字段确保大家用同一包管理器。

3. TypeScript 版本对齐

   • 在 .vscode/settings.json 中指定 "typescript.tsdk": "node_modules/typescript/lib"。
   • WebStorm 设置使用项目内的 TypeScript。

4. 调试配置共享

   • .vscode/launch.json 提供调试启动配置。
   • WebStorm 的 run/debug configurations 可提交 .idea/runConfigurations/。

5. 引导新成员

   • README 中写明推荐扩展和一键安装脚本。
   • 首次启动时通过 VS Code workspace recommendations 提示安装扩展。

最佳实践：

• 不强制编辑器品牌，但强制行为一致（保存格式化、提交前检查）。
• 把编辑器配置纳入版本控制并定期 review。
• 对 JetBrains 用户提供 .editorconfig 和 npm scripts 作为主要约定。

评分维度：

• 方案分层（40%）：能区分项目配置、CLI、扩展推荐三层
• 工具覆盖（30%）：能说明 VS Code 和 WebStorm 各自如何配置
• 可落地性（30%）：能说明 README 引导、CI 一致、不强绑定编辑器

常见错误：

• 只支持 VS Code，忽略 WebStorm 用户
• 把格式化完全交给编辑器，CI 不校验
• 编辑器配置不提交版本控制，新成员无法继承

延伸追问：

• 如果某个开发者坚持不装 Prettier 插件，怎么保证提交格式正确？
• 编辑器扩展版本不同导致提示不一致，如何处理？

相关题目：

• FB-21-EN-A-012 Git Hooks 自动化代码检查
• FB-21-EN-A-013 TypeScript compilerOptions 取舍

参考资源：

• EditorConfig 官方文档
• VS Code Workspace Recommendations

口头回答版：

编辑器一致性主要靠三层：项目级配置比如 .editorconfig、.vscode/settings.json；统一 CLI 命令比如 pnpm lint、pnpm format，CI 也跑这些；推荐扩展但不强制编辑器。TypeScript 要指定用项目里的版本。关键是行为一致，而不是大家都用同一款编辑器。

---

FB-21-EN-A-015：如何度量 CI pipeline 的反馈速度？有哪些常见瓶颈和优化手段？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：GitHub Actions、前端工程化、性能优化、CI/CD 出现频率：高频 预计回答时长：5-8 分钟

题目描述： 请说明度量 CI 反馈速度的指标，并分析常见瓶颈以及对应的优化手段。

参考答案：

核心要点：CI 反馈速度可通过“提交到结果的总时长”和“各阶段分位数耗时”来度量；瓶颈通常集中在依赖安装、全量测试、构建产物和串行任务。

详细解释：

1. 关键指标

   • Pipeline Duration：从代码推送到 CI 结束的总时间（P50/P90/P95）。
   • Time to First Feedback：第一个失败/成功的任务耗时。
   • Queue Time：任务排队等待执行的时间。
   • Flaky Rate：不稳定测试导致的重跑率。
   • Cache Hit Rate：依赖缓存、构建缓存命中率。

2. 常见瓶颈

   • 依赖安装慢：npm registry 慢、lock 文件大、未缓存 node_modules。
   • 全量 lint/test/build：没有 affected 或增量策略。
   • 串行任务：job 之间没有并行化。
   • 大产物上传/下载：dist、sourcemap、测试报告。
   • 资源不足：CI runner CPU/内存低。

3. 优化手段

   • 缓存：actions/setup-node 的 cache、Turborepo/Nx remote cache、Docker layer cache。
   • 增量：只跑 affected packages，skip 未变更的测试和构建。
   • 并行：矩阵构建、分片测试（sharding）、并行 lint/typecheck/test。
   • 精简：移除冗余步骤、按需安装依赖、用轻量 runner image。
   • 失败快退：先跑 lint/typecheck，再跑单元测试，最后 E2E。

4. 示例：GitHub Actions 缓存

- uses: actions/setup-node@v4
  with:
    node-version-file: .nvmrc
    cache: pnpm

最佳实践：

• 在 CI 日志中注入阶段时间戳，便于持续追踪。
• 对 P90 耗时设置 SLO，超过则触发优化专项。
• 区分 PR 校验和主干发布，PR 上尽量轻量。

评分维度：

• 度量指标（35%）：能说出 Pipeline Duration、Time to First Feedback、Queue Time、Cache Hit Rate 等
• 瓶颈分析（35%）：能识别安装、全量任务、串行、产物、资源瓶颈
• 优化手段（30%）：能给出缓存、增量、并行、失败快退等具体做法

常见错误：

• 只关注平均耗时，忽略 P90 和排队时间
• CI 中不缓存依赖，每次重新安装
• 所有任务串行执行，未利用矩阵或分片

延伸追问：

• CI 缓存命中率低通常是什么原因？
• 如何在不降低质量的前提下让 PR 校验在 5 分钟内完成？

相关题目：

• FB-21-CP-R-026 CI 反馈时间优化
• FB-21-EN-A-010 pnpm workspace + Turborepo

参考资源：

• GitHub Actions 缓存文档
• Turborepo Remote Cache

口头回答版：

CI 反馈速度可以看从推送到结果的总时长，以及各阶段 P50、P90 耗时。常见瓶颈是安装依赖慢、全量跑测试、任务串行、大产物上传、runner 资源不够。优化手段：缓存 node_modules 和构建缓存、只跑 affected 包、并行化任务、先跑快的检查慢的放后面。要给 P90 设 SLO，持续追踪。

---

FB-21-CO-A-016：什么是开发者反馈循环（Developer Feedback Loop）？缩短反馈循环有哪些典型手段？

题型：概念题 难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、开发者体验、性能优化、效能度量 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请解释开发者反馈循环的概念，并结合前端工程实践说明如何缩短反馈循环。

参考答案：

核心要点：开发者反馈循环指开发者执行动作到看到结果之间的时间；循环越短，开发者越容易进入心流、修复错误的成本越低。

详细解释：

1. 反馈循环的典型阶段

   • 编码阶段：保存 -> HMR -> 浏览器刷新 -> 看到效果。
   • 检查阶段：提交 -> lint/typecheck/test -> 看到结果。
   • 集成阶段：推送 -> CI -> 部署预览 -> 看到线上效果。
   • 运行阶段：用户反馈 -> 日志/监控 -> 定位问题。

2. 缩短手段

   • 编码：
     • 使用 Vite/SWC 等快速 HMR。
     • 单元测试 watch 模式，保存即跑相关测试。
     • TypeScript 错误在 IDE 中实时提示。
   • 检查：
     • pre-commit 只跑 staged 文件，自动修复。
     • CI 失败快退，先跑 lint/typecheck 再跑重任务。
   • 集成：
     • 每次 PR 自动生成预览环境（Vercel/Netlify Preview）。
     • 主干合并后自动部署到 staging。
   • 运行：
     • 实时错误监控（Sentry），快速定位 release 问题。
     • 可观测性 dashboard 关联代码版本。

3. 度量指标

   • HMR 时间、CI pipeline 时长、预览环境启动时间、MTTR（平均修复时间）。

最佳实践：

• 把反馈循环作为 DX 核心 KPI。
• 优先优化高频动作（保存、提交、PR）的等待时间。
• 保持错误信息 actionable，让开发者知道下一步怎么做。

评分维度：

• 概念理解（40%）：能说明反馈循环的阶段和缩短的意义
• 手段覆盖（35%）：能从编码、检查、集成、运行四个阶段举例
• 度量意识（25%）：能提到 HMR 时间、CI 时长、MTTR 等指标

常见错误：

• 只关注 CI 时间，忽略编码阶段的 HMR 和 IDE 提示
• 缩短反馈循环以牺牲质量为代价，比如关闭测试
• 没有度量，优化凭感觉

延伸追问：

• 如果 HMR 已经很快，但开发者仍觉得卡，还可能是什么原因？
• 如何在大型 Monorepo 中保持本地反馈循环在 1 秒内？

相关题目：

• FB-21-CO-B-001 开发者体验定义
• FB-21-PE-A-011 构建性能优化

参考资源：

• Fast Feedback Loops - Martin Fowler
• Vite HMR 文档

口头回答版：

开发者反馈循环就是从做一件事到看到结果的时间，比如保存代码到看到页面更新、提交到看到 CI 结果。循环越短，开发效率越高。缩短手段：编码阶段用快速的 HMR 和 IDE 实时类型检查；检查阶段 pre-commit 只跑改了的文件，CI 先跑快的；集成阶段用 PR 预览环境；运行阶段用 Sentry 等实时监控。高频动作的等待时间最该优先优化。

---

深入题（7 道）

FB-21-SD-P-017：如何设计一个内部开发者门户（Internal Developer Portal）？核心模块和衡量指标是什么？

题型：系统设计题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、可观测性、开发者体验、平台工程 出现频率：中频 预计回答时长：10-15 分钟

题目描述： 请设计一个内部开发者门户（Internal Developer Portal），说明它要解决的核心问题、主要功能模块、技术选型和衡量指标。

参考答案：

核心要点：内部开发者门户是 Platform Engineering 的入口层，通过统一界面暴露脚手架、服务目录、文档、CI/CD、监控、权限等能力，降低开发者使用平台工具的认知成本。

详细解释：

1. 要解决的核心问题

   • 信息分散：文档、服务、流水线、监控入口众多，开发者找不到。
   • 自助化不足：开新服务、申请权限、查看日志都要人工审批或找人。
   • 可见性差：无法直观看到系统健康度、发布状态、技术债分布。

2. 核心模块

   • Software Catalog：服务/组件/库清单，关联 owner、技术栈、依赖关系、SLA。
   • 脚手架与模板：一键创建服务、库或前端应用，自动接入 CI/CD、监控。
   • 文档与 API 门户：统一搜索技术文档、API 规范、架构决策记录（ADR）。
   • CI/CD 面板：查看最近构建、部署历史、回滚入口。
   • 可观测性聚合：Sentry 错误、Grafana 指标、日志链接一站式访问。
   • 自服务工单：权限申请、域名申请、证书续期等流程自动化。
   • 开发者反馈：NPS、痛点投票、支持频道入口。

3. 技术选型参考

   • Backstage（Spotify 开源）：插件生态丰富，适合中大型企业。
   • 自研 Next.js/Nuxt 门户：灵活度高，适合有专职平台团队的组织。
   • 数据源集成：GitHub/GitLab API、K8s API、CI/CD API、监控系统 API。

4. 衡量指标

   • 自助完成率：多少需求不需要平台团队人工介入。
   • 门户活跃 DAU/MAU。
   • 平均找到信息/完成操作的时间。
   • 开发者 NPS / CSAT。
   • 因文档/工具问题导致的支持工单数量。

最佳实践：

• 不要一开始就做大而全，先解决“最常用的 3 个入口”。
• Catalog 数据应自动同步代码仓库和 CI，避免手工维护。
• 通过插件机制让各业务线自行扩展。

评分维度：

• 问题洞察（30%）：能说明信息分散、自助化不足、可见性差等痛点
• 模块设计（40%）：能给出 Catalog、脚手架、文档、CI/CD、可观测性等核心模块
• 指标与选型（30%）：能提出可量化的指标和合理的技术选型

常见错误：

• 把门户做成静态链接集合，没有数据和自助能力
• 过度追求界面华丽，忽略信息准确性和实时性
• 没有衡量指标，上线后无法证明价值

延伸追问：

• Backstage 的 Software Catalog 如何与现有 Git 仓库保持一致？
• 如果平台能力不完善，如何防止门户变成“背锅入口”？

相关题目：

• FB-21-SD-R-024 平台工程体系设计
• FB-21-SD-R-029 组件/文档/示例一体化工具链

参考资源：

• Backstage 官方文档
• Platform Engineering 白皮书

口头回答版：

内部开发者门户是 Platform Engineering 的入口，把脚手架、服务目录、文档、CI/CD、监控、权限申请等能力统一起来。核心模块包括 Software Catalog、一键创建服务、文档与 API 门户、CI/CD 面板、可观测性聚合、自服务工单。衡量指标看自助完成率、DAU、找到信息的时间、开发者 NPS。不要一开始做太大，先把最常用的入口解决好。

---

FB-21-EN-P-018：代码生成（Code Generation）在前端工程中的应用场景和边界是什么？

题型：工程化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Babel、TypeScript、代码生成 出现频率：中频 预计回答时长：8-12 分钟

题目描述： 请说明代码生成在前端工程中的典型应用场景，并分析它适合做什么、不适合做什么。

参考答案：

核心要点：代码生成适合“结构重复、规则明确、容易因手工维护而出错”的场景；不适合处理业务逻辑复杂、变化频繁、需要高度创造性的代码。

详细解释：

1. 典型应用场景

   • API 客户端生成：从 OpenAPI/Swagger/GraphQL Schema 生成 TypeScript 类型和请求函数，避免手写 API 层。
   • 组件/页面模板：根据配置或数据库表生成 CRUD 页面、表单、列表。
   • 类型定义同步：从后端 Proto/GraphQL Schema 生成前端类型。
   • 路由/菜单生成：根据文件系统约定或配置生成路由表。
   • 国际化 key 提取：扫描源码生成翻译文件模板。
   • 图标/字体组件：把 SVG/图标字体转换为 React/Vue 组件。
   • Design Token：从 Figma/Tokens Studio 生成 CSS 变量或 JS 主题对象。

2. 生成方式

   • 编译时生成：构建前运行脚本，产物提交或不提交（如 orval、openapi-typescript）。
   • 运行时生成：利用 babel/plugin 或 unplugin 在构建时注入代码。
   • IDE/CLI 模板：如 Plop、Hygen，用于一次性文件创建。

3. 边界与风险

   • 适合做：重复性高、规则确定、数据源稳定的代码。
   • 不适合做：复杂业务逻辑、UX 细节、需要人工判断的代码。
   • 风险：生成代码可读性差、调试困难、生成器 Bug 会扩散到全仓库。

4. 最佳实践

   • 生成产物应标记“自动生成的，请勿手动修改”。
   • 在 CI 中校验生成产物与源码/Schema 是否一致。
   • 保留人工覆盖的扩展点，避免生成器成为“紧箍咒”。

评分维度：

• 场景覆盖（40%）：能列举 API 生成、组件模板、类型同步、路由生成等至少 4 个场景
• 方式理解（25%）：能区分编译时、运行时、CLI 模板三种生成方式
• 边界判断（35%）：能说明适合/不适合的场景及风险控制

常见错误：

• 把代码生成当成万能药，试图生成所有代码
• 生成产物可读性差且不标记来源，导致调试困难
• 生成器与源码不同步，导致 CI 与本地结果不一致

延伸追问：

• 如何保证生成的 API 客户端类型与后端接口实时一致？
• 代码生成和低代码/无代码平台的边界在哪里？

相关题目：

• FB-21-EN-A-009 团队级项目模板设计
• FB-21-SD-R-029 组件/文档/示例一体化工具链

参考资源：

• openapi-typescript 文档
• Plop 文档

口头回答版：

代码生成适合重复性高、规则明确的代码，比如从 Swagger 生成 TS 类型和请求函数、从数据库表生成 CRUD 页面、从 SVG 生成图标组件、从 Design Token 生成主题变量。它不适合写复杂业务逻辑和 UX 细节。生成产物要标记“自动生成请勿手动修改”，CI 要校验和 Schema 一致，并且保留人工覆盖的扩展点。

---

FB-21-EN-P-019：Dev Container 如何解决本地开发环境一致性？给出一个 .devcontainer/devcontainer.json 配置示例。

题型：工程化题 / 手写代码题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：Docker、前端工程化、开发者体验、环境一致性 出现频率：中频 预计回答时长：8-12 分钟

题目描述： 请说明 Dev Container 的工作原理，并写出一个适用于前端项目的 .devcontainer/devcontainer.json 配置示例。

参考答案：

核心要点：Dev Container 通过把开发环境（Node、系统依赖、扩展、环境变量）打包成 Docker 镜像，并让 VS Code / GitHub Codespaces 在容器内运行，从而让每位开发者获得与线上/CI 一致的本地环境。

详细解释：

1. 工作原理

   • 项目根目录下放置 .devcontainer/devcontainer.json。
   • VS Code 的 Dev Containers 扩展根据配置启动 Docker 容器。
   • 本地源码通过 volume 挂载到容器内，编辑和运行都在容器中进行。
   • 容器内预装 Node、pnpm、Git、SSH agent 等，环境完全一致。

2. 配置示例

{
  "name": "Frontend Dev Container",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "features": {
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode",
        "bradlc.vscode-tailwindcss"
      ],
      "settings": {
        "editor.formatOnSave": true,
        "typescript.tsdk": "node_modules/typescript/lib"
      }
    }
  },
  "postCreateCommand": "corepack enable && pnpm install",
  "postStartCommand": "pnpm dev",
  "forwardPorts": [5173],
  "remoteUser": "node"
}

3. 关键字段说明

   • image：基础镜像，可选 Dockerfile 自定义。
   • features：一键添加常用工具（GitHub CLI、Docker in Docker 等）。
   • customizations.vscode：自动安装扩展和设置。
   • postCreateCommand：容器创建后执行初始化命令。
   • forwardPorts：把容器端口映射到本地。

4. 落地建议

   • 镜像尽量接近 CI/生产环境。
   • 把 .devcontainer 纳入版本控制。
   • 提供“不使用 Dev Container”的降级方案（本地脚本），尊重开发者习惯。

评分维度：

• 原理理解（30%）：能说明容器化开发环境的工作方式
• 配置正确性（40%）：能写出包含 image、extensions、postCreateCommand、forwardPorts 的示例
• 落地意识（30%）：能提到 CI 一致性、版本控制、降级方案

常见错误：

• 镜像与 CI/生产环境差异大，导致容器里能跑、CI 却挂
• postCreateCommand 里跑太重的初始化，首次启动极慢
• 忽略端口转发和文件权限问题

延伸追问：

• Dev Container 和直接使用 Docker Compose 本地开发有什么区别？
• 如何加速 Dev Container 的首次构建和依赖安装？

相关题目：

• FB-21-CO-B-007 本地开发环境不一致问题
• FB-21-EN-P-022 远程开发环境落地

参考资源：

• VS Code Dev Containers 文档
• Dev Container 规范

口头回答版：

Dev Container 把开发环境打包成 Docker 镜像，VS Code 在容器里跑项目，源码通过 volume 挂进去。这样每个人本地环境都一样，跟 CI 也一致。配置里要指定基础镜像、自动装的扩展、创建后初始化命令、端口转发等。建议把 .devcontainer 提交版本控制，同时给不习惯的人留本地启动脚本。

---

FB-21-SS-P-020：如何推动团队从“各自为政”的开发环境迁移到统一的 DX 平台？

题型：软技能题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、可观测性、开发者体验、团队协同 出现频率：中频 预计回答时长：8-12 分钟

题目描述： 团队里各项目使用不同的脚手架、构建工具和 CI 配置，导致新人上手困难、维护成本高。作为技术负责人，你会如何推动统一 DX 平台的落地？

参考答案：

核心要点：统一 DX 平台是组织变革，技术方案只是基础；成功的关键在于找到“高痛点低阻力”的切入点、获得关键干系人支持、用数据和 quick win 持续证明价值。

详细解释：

1. 诊断现状

   • 收集各项目技术栈、CI 时长、onboarding 时长、常见报错/支持工单。
   • 通过问卷或访谈识别最大痛点（如环境不一致、构建慢、文档缺失）。
   • 量化当前成本：每人每月因环境/工具问题浪费的时间。

2. 制定路线图

   • Phase 1 - 快速胜利：提供一键初始化脚本、统一 lint/format、共享 CI 模板。
   • Phase 2 - 核心能力：推出团队脚手架、Dev Container、内部开发者门户。
   • Phase 3 - 平台化：自服务、可观测性、remote cache、自动化测试平台。

3. 推动策略

   • 以痛点驱动：先解决大家都头疼的问题，而不是一上来就推翻所有工具。
   • 建立联盟：找到 2-3 个愿意试点的团队，做出标杆案例。
   • 透明沟通：定期发布 DX 月报，展示节省时间、减少工单等数据。
   • 保留退出机制：不强制一刀切，允许老项目逐步迁移或维持现状。
   • 把平台当产品：设立 platform PM / owner，收集反馈并迭代。

4. 常见阻力及应对

   • “我的项目特殊”：提供插件/扩展点，让业务线保留差异。
   • “迁移成本高”：提供 codemod / 迁移脚本，并分摊到多个迭代。
   • “看不到价值”：用 before/after 数据和案例说话。

最佳实践：

• 用 RFC 流程让团队参与决策，增强 ownership。
• 设置迁移激励：迁移后减少 Code Review 摩擦、优先获得平台新能力。
• 把平台能力作为晋升/绩效的认可维度。

评分维度：

• 变革思路（40%）：能体现诊断、试点、推广、度量的完整闭环
• 利益相关方管理（30%）：能说明如何获得团队和管理层支持
• 落地策略（30%）：能给出分阶段路线、阻力应对和激励机制

常见错误：

• 只给技术方案，不关注组织沟通和变更管理
• 强制一刀切，引发业务团队抵触
• 没有数据和 quick win，导致项目烂尾

延伸追问：

• 如果某个业务线 leader 拒绝迁移，你会怎么处理？
• 如何平衡统一平台与业务团队技术自主权？

相关题目：

• FB-21-SD-P-017 内部开发者门户设计
• FB-21-SS-R-030 向管理层证明 DX 价值

参考资源：

• Platform Engineering 实践
• Spotify 工程文化

口头回答版：

推动统一 DX 平台不只是技术问题，更是组织变革。我会先诊断现状，收集各项目技术栈、CI 时长、onboarding 时间、常见工单，找到最大痛点。然后分阶段：先做快速胜利，比如统一 lint 和 CI 模板；再做团队脚手架和 Dev Container；最后平台化。过程中要找愿意试点的团队做标杆，用数据说话，保留退出机制，不强制一刀切。

---

FB-21-CP-P-021：DORA 指标和 SPACE 框架分别衡量什么？如何把它们用于前端工程效能改进？

题型：综合开放题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、性能优化、可观测性、效能度量 出现频率：高频 预计回答时长：10-15 分钟

题目描述： 请解释 DORA 指标和 SPACE 框架的含义，并说明如何把它们落地到前端团队的工程效能改进中。

参考答案：

核心要点：DORA 聚焦软件交付绩效（快和稳），SPACE 关注开发者体验与福祉；二者结合可避免只追求速度而忽视开发者健康与质量。

详细解释：

1. DORA 四项核心指标

   • Deployment Frequency（部署频率）：单位时间内成功部署到生产环境的次数。
   • Lead Time for Changes（变更前置时间）：从代码提交到上线的时间。
   • Change Failure Rate（变更失败率）：部署后导致故障的比例。
   • Time to Restore Service（服务恢复时间）：发生故障后恢复到正常状态的时间。

   DORA 把团队分为 Elite / High / Medium / Low 四级。

2. SPACE 五维框架

   • Satisfaction & Well-being：开发者满意度与身心健康。
   • Performance：系统/交付绩效（可用 DORA 衡量）。
   • Activity：开发活动量（提交、PR、构建次数）。
   • Communication & Collaboration：沟通与协作效率。
   • Efficiency & Flow：效率与心流，如等待时间、打断次数。

3. 前端团队的落地方式

   • DORA 落地：
     • 通过 CI/CD 平台采集部署频率、PR 合并到发布时长、回滚次数。
     • 前端虽然没有独立“服务”，但可以把每次 npm publish / 前端应用发布视为部署。
   • SPACE 落地：
     • 满意度：每季度 DX NPS 调研。
     • Efficiency：度量 HMR 时间、CI 时长、本地构建等待时间。
     • Collaboration：Code Review 响应时间、知识库贡献量。

4. 避免误用

   • 不要拿指标直接考核个人，否则会被“优化”。
   • 指标要配合上下文分析，比如部署频率高不一定好，可能是半成品频繁上线。
   • 定期 review 指标定义，确保与业务目标一致。

评分维度：

• DORA 理解（30%）：能准确解释四项指标含义
• SPACE 理解（30%）：能解释五维框架及与 DORA 的关系
• 落地能力（40%）：能结合前端场景给出采集和改进方案

常见错误：

• 把 DORA 当成个人 KPI，导致数据造假或行为扭曲
• 只关注 DORA 速度指标，忽略 SPACE 中的满意度和协作
• 指标采集后没有行动，沦为数字游戏

延伸追问：

• 如果你的团队 Deployment Frequency 很低，你会先优化哪一环？
• 如何防止指标被“游戏化”？

相关题目：

• FB-21-CO-B-001 开发者体验定义
• FB-21-EN-A-015 CI 反馈速度度量

参考资源：

• DORA 官方报告
• SPACE of Developer Productivity - ACM Queue

口头回答版：

DORA 四个指标：部署频率、变更前置时间、变更失败率、服务恢复时间，衡量交付又快又稳。SPACE 是更全面的框架，包含满意度、绩效、活动、协作、效率与心流。前端落地时，可以把 npm 发布/前端应用发布当部署，采集 CI 时长、HMR 时间、CR 响应时间，同时做 DX NPS 调研。指标不要拿来考核个人，要配合上下文分析和改进行动。

---

FB-21-EN-P-022：远程开发环境（Remote Development）在大型前端项目中的优势和落地挑战是什么？

题型：工程化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：Docker、前端工程化、开发者体验、远程开发 出现频率：低频 预计回答时长：8-12 分钟

题目描述： 请分析远程开发环境（如 GitHub Codespaces、Gitpod、自研远程容器）对大型前端项目的价值，以及落地过程中需要克服的挑战。

参考答案：

核心要点：远程开发环境把计算资源集中到云端，能解决本地机器性能不足、环境一致性差、代码安全等问题，但也带来网络延迟、成本、开发者习惯和离线场景的挑战。

详细解释：

1. 优势

   • 环境一致性：所有人在相同镜像中开发，消除“我本地能跑”。
   • 性能弹性：大型项目构建/测试需要高 CPU/内存，远程环境可按需分配。
   • 安全合规：源码不落地，降低泄露风险；权限统一管控。
   • 快速 onboarding：新成员通过浏览器或客户端即可开始编码。
   • 资源可观测：平台团队可统一监控环境使用率、成本和性能。

2. 落地挑战

   • 网络延迟：HMR、文件同步、端口转发依赖低延迟网络。
   • 成本：每台远程环境持续运行会产生计算和存储费用。
   • 离线工作：网络中断时无法继续开发。
   • 本地工具依赖：设计师、移动端调试、本地模拟器可能难以搬到远程。
   • 开发者习惯：部分工程师偏好本地文件系统和自定义工具。

3. 适用场景

   • 大型 Monorepo 构建慢，本地机器扛不住。
   • 安全要求高的代码库（金融、政府）。
   • 新成员多、机器配置不统一的团队。

4. 落地策略

   • 先试点核心团队，收集反馈再推广。
   • 提供 hybrid 模式：远程为主，本地容器/Dev Container 为 fallback。
   • 预置常用环境镜像，利用预构建（prebuild）减少首次启动时间。
   • 监控使用率，自动休眠不活跃环境以控制成本。

评分维度：

• 优势分析（35%）：能说明一致性、性能、安全、onboarding 等价值
• 挑战识别（35%）：能提到网络、成本、离线、本地工具、习惯等挑战
• 落地策略（30%）：能给出试点、hybrid、预构建、成本控制的方案

常见错误：

• 认为远程开发适合所有人和所有场景
• 忽略网络延迟对 HMR 体验的影响
• 成本失控，没有自动休眠和配额管理

延伸追问：

• 远程开发环境和 Dev Container 有什么关系？
• 如果团队在中国访问 GitHub Codespaces 不稳定，怎么解决？

相关题目：

• FB-21-EN-P-019 Dev Container 配置与实践
• FB-21-CO-B-007 本地开发环境不一致问题

参考资源：

• GitHub Codespaces 文档
• Gitpod 文档

口头回答版：

远程开发环境把计算和代码放到云端，好处是环境一致、性能弹性、代码安全、onboarding 快。挑战是网络延迟、成本高、离线没法用、本地调试工具不好搬、要改变开发者习惯。适合大型 Monorepo 或安全要求高的项目。落地时先试点，提供本地 Dev Container 做 fallback，用预构建减少首次启动，还要自动休眠控制成本。

---

FB-21-SC-P-023：如何为新成员设计高效的 onboarding 流程？请给出 30-60-90 天计划框架。

题型：场景设计题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Storybook、测试策略、团队协同 出现频率：中频 预计回答时长：8-12 分钟

题目描述： 请设计一套新成员 onboarding 流程，覆盖环境准备、知识传递、代码实践和反馈机制，并给出 30-60-90 天的大致计划。

参考答案：

核心要点：高效的 onboarding 不是一次性培训，而是“环境即代码、知识可检索、任务有导师、进度可度量”的持续过程。

详细解释：

1. 入职前（Day -7 ~ Day 0）

   • 自动创建账号、邮箱、GitHub/GitLab 权限。
   • 发送 onboarding checklist 和预读文档链接。
   • 分配导师（buddy）并预约首次 1:1。

2. 第 1 个月（0-30 天）：跑通环境，理解流程

   • 使用 Dev Container / 一键脚本在 1 小时内跑起项目。
   • 完成“good first issue”或文档/测试小任务。
   • 学习团队规范：Git 工作流、Code Review、发布流程。
   • 导师每周检查进度，回答阻塞问题。

3. 第 2 个月（31-60 天）：独立交付小功能

   • 参与真实需求，从需求评审到上线完整走一次。
   • 学习架构和关键模块：组件库、状态管理、BFF、监控。
   • 完成一次技术分享或文档补充。

4. 第 3 个月（61-90 天）：承担更大责任

   • 独立负责一个小模块或一次发布。
   • 参与 on-call 或值班轮次（如适用）。
   • 给 onboarding 流程反馈，形成改进闭环。

5. 支撑机制

   • 文档与视频：快速开始指南、架构概览、常见错误 FAQ。
   • 沙箱项目：提供一个安全的练习仓库，避免直接碰生产代码。
   • ** checklist 自动化**：用 Notion/Trello/GitHub Projects 跟踪进度。
   • 反馈机制：30/60/90 天分别做一次访谈，持续优化流程。

最佳实践：

• 把 onboarding 时间作为团队 KPI，目标是“第一天能提交代码”。
• 让新成员在第二周内完成一次上线，建立成就感。
• 鼓励新成员挑 onboarding 文档的刺，反向促进文档质量。

评分维度：

• 流程完整性（40%）：能覆盖环境、知识、任务、导师、反馈等维度
• 30-60-90 计划（30%）：能给出分阶段目标
• 可落地性（30%）：能提到自动化、checklist、沙箱、导师机制

常见错误：

• onboarding 变成一次性讲座，没有后续跟进
• 让新成员直接解决复杂线上问题，导致挫败感
• 文档陈旧，新成员按文档操作频频报错

延伸追问：

• 如何衡量 onboarding 的成功与否？
• 远程团队 onboarding 和线下团队有什么不同？

相关题目：

• FB-21-CO-B-008 内部开发者文档
• FB-21-EN-P-019 Dev Container 配置

参考资源：

• The First 90 Days
• Onboarding Docs at Stripe

口头回答版：

高效的 onboarding 要让环境能一键跑起来、知识能搜到、任务有导师带、进度可追踪。30 天内主要是跑通环境、做 good first issue、学规范；60 天内独立交付小功能、走完整需求流程；90 天内能独立负责小模块或发布。还要有沙箱练习、文档反馈、定期访谈，让新成员也能反向优化流程。

---

架构题（7 道）

FB-21-SD-R-024：为百人前端团队设计一个平台工程（Platform Engineering）体系，关键能力、组织形式和度量指标是什么？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、可观测性、性能优化、平台工程 出现频率：中频 预计回答时长：20-30 分钟

题目描述： 假设你是一家百人规模前端团队的架构师，请设计一套平台工程（Platform Engineering）体系，说明它应提供的关键能力、团队组织形式、与业务团队的协作方式以及度量指标。

参考答案：

核心要点：平台工程的核心是把重复、复杂、易错的基础设施和工程能力沉淀为内部平台产品，让业务团队自助使用；成功的平台必须有清晰的产品边界、可量化的价值和持续运营。

详细解释：

1. 关键能力层

   • 统一研发底座：脚手架、组件库、设计系统、Monorepo 工具链、Dev Container。
   • 构建与交付平台：CI/CD pipeline 模板、远程缓存、制品管理、灰度发布。
   • 可观测性平台：错误监控、性能监控、埋点、日志、告警。
   • 自服务平台：服务目录、环境申请、域名/证书、权限审批。
   • 质量门禁：自动化测试、Code Review 机器人、安全扫描、依赖审计。
   • 知识门户：文档、ADR、最佳实践、 onboarding 路径。

2. 组织形式

   • 平台产品组（Platform Team）：5-10 人，负责平台能力规划、建设和运营。
   • 业务平台联络人（Platform Champion）：每个业务线指定 1 人，反馈需求并推广使用。
   • 虚拟兴趣组：构建性能、测试、组件库等方向的小组，鼓励跨团队贡献。
   • 产品化运营：平台组像对外产品一样处理需求、发布版本、写 changelog。

3. 与业务团队协作

   • 通过 RFC 收集需求，平台组评估优先级。
   • 提供 migration guide 和 codemod，降低迁移成本。
   • 设立 SLI/SLO：平台服务的可用性、响应时间、缓存命中率。
   • 定期举办 office hour，处理业务团队阻塞问题。

4. 度量指标

   • 效率类：CI 时长、构建时间、onboarding 时间、自助完成率。
   • 质量类：变更失败率、线上 Bug 数、安全漏洞修复时长。
   • 满意度类：开发者 NPS、平台工单响应时间、文档搜索成功率。
   • 采用类：平台能力覆盖率、老项目迁移率。

最佳实践：

• 平台能力优先做“高痛点、高频使用”的（如构建、CI、组件库）。
• 保持“可选而非强制”，允许业务线在统一底座上做扩展。
• 平台组要有产品思维和用户运营能力，而不是只写工具。

评分维度：

• 能力设计（35%）：能覆盖研发底座、构建交付、可观测、自服务、质量、知识等能力
• 组织与协作（30%）：能说明平台组、champion、RFC、SLO 等机制
• 度量体系（35%）：能给出效率、质量、满意度、采用率四类指标

常见错误：

• 平台组闭门造车，不了解业务真实痛点
• 过度统一，扼杀业务团队技术选型自由
• 没有度量指标，无法证明平台价值

延伸追问：

• 平台能力应该自建还是采购 SaaS？决策依据是什么？
• 平台组如何避免成为业务团队的“外包”？

相关题目：

• FB-21-SD-P-017 内部开发者门户设计
• FB-21-SS-R-030 向管理层证明 DX 价值

参考资源：

• Team Topologies - Platform Team
• Platform Engineering 社区

口头回答版：

平台工程是把重复复杂的基础设施能力沉淀成内部平台产品，让业务团队自助用。关键能力包括统一研发底座、构建与交付平台、可观测性、自服务、质量门禁、知识门户。组织上要有平台产品组、业务线 champion、兴趣组和 RFC 流程。度量指标看效率、质量、满意度和采用率。平台组要有产品思维，优先做高频痛点，保持可选而非强制。

---

FB-21-SD-R-025：如何设计一套可扩展的脚手架生态，支持多业务线、多技术栈？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Vite、Babel、脚手架、Monorepo 出现频率：中频 预计回答时长：15-25 分钟

题目描述： 请设计一套可扩展的脚手架生态，支持公司内多业务线（如电商、金融、国际化）和多技术栈（React、Vue、小程序、Node BFF）的项目初始化，并说明如何管理模板版本和扩展机制。

参考答案：

核心要点：可扩展脚手架应采用“核心引擎 + 插件/模板市场”的架构：核心负责 CLI 交互、文件生成、依赖安装和生命周期；模板和插件由业务线维护，通过版本化分发。

详细解释：

1. 整体架构

┌─────────────────────────────────────┐
│  CLI Engine (create-x)              │
│  - 交互式问卷 / 参数解析             │
│  - 模板选择 / 插件选择               │
│  - 文件渲染（EJS / Handlebars）      │
│  - 依赖安装 & 后处理脚本             │
└──────────┬──────────────────────┬───┘
           │                      │
    ┌──────▼──────┐        ┌──────▼──────┐
    │ 官方模板库   │        │ 业务线模板   │
    │ React/Vue   │        │ 电商/金融   │
    │ Node/小程序 │        │ 国际化/H5   │
    └─────────────┘        └─────────────┘
           │                      │
           └──────────┬───────────┘
                      │
               ┌──────▼──────┐
               │ 插件市场     │
               │ lint/test   │
               │ CI/deploy   │
               │ monitor/i18n│
               └─────────────┘

2. 核心设计

   • 模板即 npm 包：每个模板是一个独立包，带 template.json 描述元数据（名称、技术栈、维护者、版本约束）。
   • 插件机制：在模板基础上叠加能力，如 plugin-eslint、plugin-cypress、plugin-i18n。
   • 渲染引擎：支持 EJS / Handlebars 占位符替换，按问卷答案生成文件。
   • 生命周期钩子：beforeCreate、afterInstall、postProcess，允许模板自定义逻辑。

3. 版本管理

   • 模板和插件独立 SemVer 版本。
   • CLI 引擎支持 create-x@latest 和 create-x@2.x 多版本并存。
   • 提供升级命令 x upgrade，通过 codemod 自动迁移存量项目。
   • 在内部 registry 中维护模板索引，定期清理废弃模板。

4. 扩展与治理

   • 业务线可通过私有 registry 发布自己的模板。
   • 官方模板组负责核心规范和兼容性审核。
   • 模板必须包含 README、测试、CI 示例和升级日志。
   • 通过脚手架生成的项目自动接入内部平台（监控、CI、门户）。

最佳实践：

• 不要让 CLI 引擎包含业务逻辑，保持薄和通用。
• 模板开发也要有单元测试，确保生成产物可构建。
• 提供 dry-run 模式，让使用者在真正生成前预览结果。

评分维度：

• 架构设计（40%）：能画出核心引擎 + 模板 + 插件的分层
• 扩展机制（30%）：能说明模板即 npm 包、插件、生命周期、业务线扩展
• 版本与治理（30%）：能说明 SemVer、升级命令、codemod、审核机制

常见错误：

• 把所有模板逻辑都塞在 CLI 引擎里，导致引擎臃肿
• 模板没有版本管理，生成结果不可复现
• 忽略业务线差异，强制统一模板

延伸追问：

• 如果两条业务线都需要 React，但技术细节差异很大，是复用模板还是拆成两个？
• 脚手架生成的项目如何自动接入已有的内部开发者门户？

相关题目：

• FB-21-EN-B-002 前端脚手架解决的问题
• FB-21-EN-A-009 团队级项目模板设计

参考资源：

• Yeoman 架构
• create-vite 源码

口头回答版：

可扩展脚手架应该是核心引擎加模板市场加插件市场的结构。核心引擎负责交互、文件渲染、依赖安装；模板和插件做成独立 npm 包，业务线可以发布自己的。模板用 EJS 渲染，支持生命周期钩子。版本要独立 SemVer，提供升级命令和 codemod。官方负责规范和审核，业务线在统一底座上扩展。

---

FB-21-CP-R-026：如何在保证质量的前提下将 CI 反馈时间从 30 分钟降到 5 分钟？给出分层优化方案。

题型：综合开放题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：GitHub Actions、性能优化、前端工程化、测试策略 出现频率：高频 预计回答时长：15-25 分钟

题目描述： 某大型前端项目 CI 总时长 30 分钟，严重影响开发效率。请给出在不降低质量的前提下，将 CI 反馈时间压缩到 5 分钟以内的分层优化方案。

参考答案：

核心要点：CI 提速要分层治理：第一层让依赖和构建“可缓存”；第二层让任务“按需跑”；第三层让执行“并行化、分片化”；第四层用远程/分布式能力兜底。

详细解释：

1. 第一层：缓存最大化

   • 依赖缓存：缓存 ~/.pnpm-store、node_modules、.turbo。
   • 构建缓存：启用 Turborepo / Nx remote cache，未变更包直接复用产物。
   • Docker layer cache：CI 镜像分层，避免重复安装系统依赖。

2. 第二层：增量与 affected

   • 只跑受变更影响的包和测试（turbo run test --affected）。
   • 分支保护策略：lint/typecheck 全量但轻量，测试/构建走 affected。
   • 对公共底层包的改动才触发全量测试。

3. 第三层：并行化与分片

   • lint、typecheck、单元测试、E2E 并行 job。
   • 单元测试按文件数分片（jest --shard=1/4 / vitest --shard）。
   • E2E 按 spec 文件分片到多个 runner。
   • 使用矩阵策略在多个 runner 上并行。

4. 第四层：远程/分布式

   • 使用 GitHub Actions larger runners 或自建 runner 集群。
   • 使用 distributed task execution（Nx Cloud / Turborepo remote cache）。
   • 对原生构建（如 Rust/WASM）使用专用 runner。

5. 失败快退

   • 第一步跑 lint + typecheck（约 1 分钟）。
   • 失败立即终止 pipeline，不跑后续重任务。
   • E2E 仅在关键路径或 nightly 运行，PR 上跑 smoke test。

6. 示例：分层 pipeline

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          cache: pnpm
      - run: pnpm install
      - run: pnpm lint
      - run: pnpm typecheck
  test:
    needs: gate
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    runs-on: ubuntu-latest
    steps:
      - run: pnpm test --shard=${{ matrix.shard }}/4
  build:
    needs: gate
    runs-on: ubuntu-latest
    steps:
      - run: pnpm build --remote-cache

最佳实践：

• 建立 CI 时长基线，按阶段度量优化收益。
• 对 flaky test 零容忍，重跑会严重拖慢反馈。
• 区分 PR 校验和主干发布，PR 轻量、主干完整。

评分维度：

• 分层思路（40%）：能清晰划分缓存、增量、并行、远程四层
• 具体手段（35%）：能给出缓存策略、affected、分片、失败快退等做法
• 质量保障（25%）：能说明如何在提速同时不降低 lint、类型、测试覆盖

常见错误：

• 为了快而跳过类型检查或测试
• 全量任务串行执行，未做增量和分片
• 只加机器，不优化任务结构

延伸追问：

• 如果测试本身就要跑 20 分钟，怎么在 5 分钟内得到反馈？
• 如何识别并治理拖慢 CI 的 flaky test？

相关题目：

• FB-21-EN-A-015 CI 反馈速度度量
• FB-21-SD-R-027 Monorepo 远程缓存与任务调度

参考资源：

• GitHub Actions 性能优化
• Turborepo Remote Caching

口头回答版：

CI 提速要分层来：第一层最大化缓存，依赖和构建产物都缓存；第二层只跑 affected，不变动的包不重复跑；第三层并行化、分片化，测试拆到多个 runner；第四层用远程缓存或更大 runner。还要失败快退，先跑 lint 和 typecheck，失败就停。PR 可以只做轻量校验，E2E 放 nightly。这样 30 分钟降到 5 分钟是可行的。

---

FB-21-SD-R-027：设计一个 Monorepo 构建缓存和分布式任务调度方案（remote cache + task graph）。

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：pnpm、Turborepo、Monorepo、性能优化、前端工程化 出现频率：中频 预计回答时长：15-25 分钟

题目描述： 请设计一个 Monorepo 的构建缓存和分布式任务调度方案，要求支持跨团队共享缓存、精确的任务依赖图、安全的缓存失效策略，并说明关键模块和数据流。

参考答案：

核心要点：方案的核心是“任务图（task graph）+ 内容寻址缓存 + 远程缓存服务”；通过精确的输入哈希决定缓存命中，通过分布式执行器并行调度任务。

详细解释：

1. 整体架构

Developer/CI
      │
      ▼
┌─────────────┐     ┌──────────────────┐
│ Task Runner │────▶│ Remote Cache     │
│ (Turborepo/ │     │ (S3/Redis/自建)  │
│  Nx)        │◀────│                  │
└──────┬──────┘     └──────────────────┘
       │
       ▼
┌─────────────────────────────┐
│ Distributed Execution Cluster│
│  - 多个 worker node          │
│  - 按 task graph 分配任务    │
└─────────────────────────────┘

2. 任务图（Task Graph）

   • 从 turbo.json / project.json 解析每个 package 的任务和依赖。
   • build 依赖 ^build（上游依赖的 build），test 依赖 build。
   • 图是无环的，拓扑排序后调度。

3. 缓存策略

   • 输入哈希：package 源码、依赖版本、环境变量、构建配置共同参与哈希。
   • 输出指纹：产物文件哈希，用于验证缓存完整性。
   • 远程缓存：命中时从 S3/Redis 下载产物；未命中时本地构建后上传。
   • 缓存失效：环境变量、依赖版本、配置文件变化自动失效。

4. 安全与隔离

   • 缓存 key 包含 team/project，避免跨项目污染。
   • 敏感环境变量（如 token）不参与缓存 key，构建时注入。
   • 提供 turbo run build --force 强制跳过缓存。

5. 分布式执行

   • 任务拆分为小单元，发送到 worker pool。
   • worker 根据资源标签选择（如 E2E 任务需要 GPU/高内存）。
   • 调度器考虑数据局部性，优先把任务调度到已有缓存的节点。

6. 监控与运营

   • 缓存命中率、平均任务耗时、worker 利用率 dashboard。
   • 缓存容量和 TTL 管理，定期清理冷门产物。

最佳实践：

• 精确声明每个任务的 inputs 和 outputs，避免过度或不足。
• 远程缓存服务要有多 region 部署，降低下载延迟。
• 在 CI 中优先恢复远程缓存，再安装依赖。

评分维度：

• 架构设计（35%）：能画出 task runner、remote cache、execution cluster 的关系
• 缓存策略（35%）：能说明输入哈希、输出指纹、失效条件、安全隔离
• 分布式调度（30%）：能说明任务图、worker 分配、数据局部性

常见错误：

• 缓存 key 只包含文件内容，忽略依赖版本和环境变量
• 输出产物声明不全，导致缓存命中但下游缺失
• 远程缓存不做权限隔离，导致跨团队污染

延伸追问：

• 如果某个任务是非确定性的（如包含时间戳），如何保证缓存正确？
• 分布式执行时，如何调试失败的任务？

相关题目：

• FB-21-EN-A-010 pnpm workspace + Turborepo
• FB-21-CP-R-026 CI 反馈时间优化

参考资源：

• Turborepo Task Pipeline
• Nx Distributed Task Execution

口头回答版：

Monorepo 构建缓存方案核心是任务图加内容寻址缓存加远程缓存服务。任务图按依赖关系拓扑排序，比如 build 要等上游 build 完。缓存 key 由源码、依赖、配置、环境变量共同哈希决定。远程缓存存在 S3 或 Redis，命中就下载产物，没命中就构建上传。分布式调度把任务发到 worker pool，考虑数据局部性。要做好安全隔离，避免跨项目污染。

---

FB-21-CP-R-028：如何从 DX 角度度量并改进自动化测试的投资回报率（ROI）？

题型：综合开放题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：测试策略、Jest、Cypress、Playwright、前端工程化 出现频率：中频 预计回答时长：15-20 分钟

题目描述： 请从开发者体验角度，设计一套度量自动化测试 ROI 的方法，并说明如何根据度量结果改进测试策略。

参考答案：

核心要点：测试的 ROI 不仅看 Bug 拦截数，还要看它对开发者信心、反馈速度、维护成本的影响；好的测试策略应在“覆盖率、速度、稳定性、可维护性”之间找到平衡。

详细解释：

1. ROI 度量维度

   • 成本侧：
     • 编写测试的时间。
     • CI 运行时间 × 频率。
     • 测试失败后的调试时间。
     • 测试维护成本（随代码变更的修改量）。
   • 收益侧：
     • 拦截的 Bug 数 / 严重级别。
     • 线上故障中本可被测试拦截的比例。
     • 发布前是否需要大量手工回归。
     • 开发者对发布的信心评分。

2. 关键指标

   • 测试速度：单元测试 < 1s/文件，E2E 控制在合理范围。
   • Flaky Rate：不稳定测试比例，目标 < 1%。
   • Coverage by Risk：按业务风险加权覆盖率，而非单纯行覆盖。
   • Mutation Score：变异测试分数，衡量测试有效性。
   • MTTR for Test Failure：测试失败后平均修复时间。

3. 改进策略

   • 金字塔分层：70% 单元、20% 集成、10% E2E，避免倒三角。
   • 测试左移：在 IDE/pre-commit 阶段跑关键单元测试。
   • 精准测试：只跑与变更相关的测试（Jest --changedSince / affected）。
   • 不稳定测试治理：flaky test 立即 quarantine 或修复，不能放任。
   • 测试即文档：用 Given-When-Then 风格，让测试可读可维护。

4. 工具示例

   • 单元：Vitest / Jest。
   • 组件：Storybook + Testing Library。
   • E2E：Playwright / Cypress。
   • 覆盖率与变异：Codecov / Stryker。

最佳实践：

• 定期召开测试复盘会，分析漏测 Bug 和 flaky test。
• 把测试质量纳入 Code Review 标准。
• 对 ROI 低的测试要敢于删除或重构，而不是一味增加。

评分维度：

• ROI 度量（40%）：能从成本和收益两侧提出指标
• 指标体系（30%）：能提到 flaky rate、风险覆盖、mutation score 等
• 改进策略（30%）：能说明测试金字塔、左移、精准测试、不稳定治理

常见错误：

• 只看代码覆盖率，忽略测试质量和稳定性
• 测试写得过多过细，维护成本超过收益
• 对 flaky test 容忍，导致 CI 信任度下降

延伸追问：

• 如果某个模块测试覆盖率很高但线上 Bug 仍然很多，可能是什么原因？
• 如何说服业务方投入时间写测试而不是赶功能？

相关题目：

• FB-21-EN-A-012 Git Hooks 自动化代码检查
• FB-21-SC-P-023 新成员 onboarding 流程

参考资源：

• Google Testing Blog - Flaky Tests
• Playwright Best Practices

口头回答版：

测试 ROI 不能只看 Bug 拦截数，还要看开发信心和成本。成本包括写测试、跑 CI、调试维护的时间；收益包括拦截 Bug、减少手工回归、提升发布信心。指标看测试速度、flaky rate、风险加权覆盖率、mutation score。改进策略：测试金字塔、左移、精准测试只跑相关用例、立即治理 flaky test。ROI 低的测试要敢于删掉。

---

FB-21-SD-R-029：设计一个前端组件/文档/示例一体化的内部工具链。

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：Storybook、Design Token、前端工程化、文档、组件库 出现频率：中频 预计回答时长：15-25 分钟

题目描述： 请设计一套内部工具链，让前端组件库的开发、文档编写、交互示例、视觉回归测试和 Design Token 管理能够一体化协作，提升组件复用率和开发者体验。

参考答案：

核心要点：一体化工具链的核心是“单一数据源”：组件源码即文档、示例即测试、Token 即主题；通过 Storybook + Design Token + 测试工具链打通开发和消费端。

详细解释：

1. 工具链架构

Figma / Tokens Studio
        │
        ▼
Design Tokens (JSON) ───▶ Style Dictionary ───▶ CSS Variables / JS Theme
        │
        ▼
Component Source (React/Vue)
        │
        ├──▶ Storybook (文档 + 交互示例 + 控件面板)
        │
        ├──▶ Unit/Interaction Tests (Testing Library)
        │
        ├──▶ Visual Regression (Chromatic / Loki)
        │
        └──▶ VitePress / Docusaurus (设计指南)

2. 关键模块

   • 组件源码：放在 packages/ui，每个组件目录包含 index、stories、tests、styles。
   • Storybook：
     • 用 MDX 写文档，stories 即示例。
     • 使用 Controls 让开发者在线调 props。
     • 集成 design token 文档插件。
   • Design Token 管理：
     • Token 从 Figma/Tokens Studio 同步到 JSON。
     • Style Dictionary 生成 CSS 变量、JS 主题、Tailwind 配置。
     • 文档站点自动展示 Token 表格和色板。
   • 测试：
     • 单元/交互测试：Testing Library + Jest/Vitest。
     • 视觉回归：Chromatic 或 Loki，捕获 UI 变化。
   • 文档站点：
     • VitePress/Docusaurus 承载设计原则、使用规范、迁移指南。
     • 自动从 Storybook 和 Token 数据生成部分页面。

3. 一体化收益

   • 组件开发者写 stories 即完成文档和示例。
   • 设计师改 Token 后，代码和文档同步更新。
   • 消费者通过 Storybook 即可查看用法和复制代码。

4. 治理与扩展

   • 组件新增必须包含 stories 和测试，否则 CI 失败。
   • 通过 Monorepo 版本管理，组件库独立发布。
   • 提供 codemod 辅助老项目升级组件。

最佳实践：

• 文档和示例要靠近代码，避免不同步。
• 视觉回归基线要稳定，避免频繁误报。
• Token 命名要语义化，支持主题切换。

评分维度：

• 架构设计（40%）：能画出组件源码、Storybook、Token、测试、文档的关系
• 模块能力（30%）：能说明 Storybook、Design Token、视觉回归、文档站点的作用
• 一体化收益（30%）：能说明单一数据源、减少重复劳动、提升复用率

常见错误：

• 文档和示例与源码分离，导致长期不同步
• Token 只维护在代码里，设计师无法参与
• 视觉回归没有稳定基线，导致大量误报

延伸追问：

• 如何保证 Design Token 在多技术栈（React、Vue、小程序）间一致？
• 组件库文档站点和内部开发者门户是什么关系？

相关题目：

• FB-21-CO-B-008 内部开发者文档
• FB-21-EN-P-018 代码生成应用场景

参考资源：

• Storybook 官方文档
• Style Dictionary 文档

口头回答版：

一体化工具链的核心是单一数据源。组件源码同时作为文档、示例和测试的基础。用 Storybook 写 stories 就是写文档和交互示例；Design Token 从 Figma 同步到 JSON，通过 Style Dictionary 生成 CSS 变量和 JS 主题；测试用 Testing Library，视觉回归用 Chromatic；设计指南用 VitePress。这样组件开发者写一次，文档、示例、Token、测试都同步，消费者也容易复用。

---

FB-21-SS-R-030：作为前端架构师，如何向管理层证明 DX 投入的业务价值？

题型：软技能题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、可观测性、性能优化、团队协同 出现频率：高频 预计回答时长：10-15 分钟

题目描述： 管理层更关注业务目标和成本控制，请说明你会如何用数据和案例向管理层证明开发者体验（DX）和工程效能投入的价值。

参考答案：

核心要点：证明 DX 价值要把技术指标翻译成业务语言：时间、金钱、风险、速度和人才保留；用 before/after 数据、对标行业和具体业务收益说话。

详细解释：

1. 建立基线

   • 度量当前状态：CI 时长、构建时间、onboarding 天数、测试 flaky rate、线上故障数、支持工单量。
   • 通过匿名问卷获取开发者满意度（NPS）和每周因工具问题浪费的时间。

2. 业务价值转化

   • 时间 = 金钱：
     • 如果 100 名工程师每人每天因构建/环境/工具问题浪费 30 分钟，按人力成本折算就是每年数百万。
   • 速度 = 市场竞争力：
     • CI 从 30 分钟降到 5 分钟，每天可多迭代 1-2 次，缩短需求上线周期。
   • 质量 = 风险成本：
     • 自动化测试和类型检查减少上线故障，降低回滚和客户投诉成本。
   • 体验 = 人才保留：
     • 好的 DX 提升招聘吸引力和员工留存，降低招聘和培训成本。

3. 呈现方式

   • Quick Win 优先：先做低成本高影响的改进，比如缓存、统一 lint，快速拿到数据。
   • Dashboard：建立 DX 看板，展示 CI 时长趋势、构建时间、NPS、故障率。
   • 案例故事：用具体项目说明迁移前后的差异。
   • 行业对标：引用 DORA 报告，说明 Elite 团队的发布频率和恢复时间。

4. 管理层沟通话术

   • 不要讲“我们引入了 Turborepo”，而要讲“部署频率提升了 X%，上线回滚减少了 Y”。
   • 把 DX 投资与 OKR/KPI 对齐，如“支持业务线 Q3 发布 N 个需求”。
   • 明确 ROI 计算方式和预期回报周期。

最佳实践：

• 设立 DX 专项，每季度向管理层汇报。
• 让业务团队负责人也参与站台，分享效率提升体验。
• 将节省的工程师时间折算为可投入新功能开发的时间。

评分维度：

• 业务翻译能力（40%）：能把技术指标转化为时间、成本、风险、人才价值
• 数据意识（30%）：能说明基线、看板、before/after、ROI 计算
• 沟通能力（30%）：能给出面向管理层的表达方式和案例

常见错误：

• 只讲技术细节，不讲业务收益
• 没有基线数据，空口说效率提升
• 过度承诺短期回报，忽视长期积累

延伸追问：

• 如果管理层说“先把功能做完再谈 DX”，你怎么回应？
• DX 投资和直接业务功能开发如何平衡资源？

相关题目：

• FB-21-CP-P-021 DORA 与 SPACE
• FB-21-SS-P-020 推动统一 DX 平台

参考资源：

• DORA 报告
• The Business Value of Developer Experience

口头回答版：

向管理层证明 DX 价值，关键是把技术指标翻译成业务语言。先建立基线：CI 多长、构建多慢、onboarding 几天、故障多少。然后算时间成本，比如 100 人每天浪费 30 分钟就是很大一笔钱；再算速度收益，CI 快了每天能多迭代；还有质量收益减少回滚，以及体验收益留住人才。呈现时用看板、案例、行业对标，讲“部署频率提升多少、回滚减少多少”，而不是讲技术名词。

---

基础题（8 道）

FB-21-CO-B-031：什么是开发者反馈循环？为什么短反馈循环对 DX 重要？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：开发者体验、效能度量、前端工程化、反馈循环 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请解释开发者反馈循环的含义，并说明为什么缩短反馈循环能显著提升开发者体验。

参考答案：

核心要点：开发者反馈循环是从执行动作（编码、保存、提交、部署）到获得结果的时间窗口；窗口越短，迭代越流畅，错误修复成本越低。

详细解释：

1. 编码阶段：IDE 类型提示、ESLint 实时报错、自动补全。
2. 保存阶段：HMR 刷新、单元测试自动运行。
3. 提交阶段：pre-commit 检查、CI 初步结果。
4. 部署阶段：预览环境、自动化测试、线上监控。

最佳实践：

• 本地开发用 HMR，反馈控制在秒级。
• 提交前 lint-staged 只检查变更文件。
• CI 分层：快速门禁先跑，重任务后跑或并行。
• 错误信息包含位置、原因、修复建议和文档链接。

评分维度：

• 概念理解（40%）：能描述反馈循环及四个环节
• 价值阐述（35%）：能说明对效率、心流、缺陷修复成本的影响
• 落地举例（25%）：能结合 HMR、lint-staged、CI 分层举例

常见错误：

• 把反馈循环仅理解为 CI 反馈，忽略编码和保存阶段
• 只优化单一环节，忽略端到端反馈链

延伸追问：

• 你们团队 CI 反馈时间是多少？最慢环节在哪里？
• 如果某个检查必须跑很久，如何缩短反馈又不牺牲质量？

相关题目：

• FB-21-PE-A-011 构建性能优化
• FB-21-CP-R-026 CI 反馈时间优化

参考资源：

• Martin Fowler - Developer Experience
• DORA Core Model

口头回答版：

开发者反馈循环就是做完一个动作到看到结果的时间。比如保存后 HMR 多快刷新、提交后 CI 多久出结果。反馈越短，开发者越能专注，错误越早发现。好的 DX 要让编码、保存、提交、部署每个环节都快，同时保证检查质量。

---

FB-21-EN-B-032：package.json 中的 scripts 设计应遵循哪些原则？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、npm、pnpm、开发者体验 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请说明前端项目中 package.json scripts 的命名、组织和文档化原则，并给出常用脚本示例。

参考答案：

核心要点：scripts 是开发者与项目的“入口面板”，应语义清晰、职责单一、可组合、跨平台一致，让新成员无需读源码即可知道如何开发、测试和发布。

详细解释：

1. 命名原则：用通用动词 dev、build、test、lint，用冒号做命名空间 test:unit、test:e2e。
2. 组织原则：单一职责、可组合、跨平台（避免裸 rm -rf，用 rimraf）。
3. 常用脚本：dev、build、preview、test、lint、lint:fix、format、typecheck、prepare。
4. 文档化：README 列出最常用的 3-5 条脚本。

最佳实践：

• 优先使用项目本地依赖，避免全局 CLI。
• 保持 script 名称与团队其他项目一致。
• 用 corepack / packageManager 统一包管理器。

评分维度：

• 命名规范（40%）：能说出语义化、命名空间、生命周期
• 组织能力（30%）：能说明单一职责、可组合、跨平台
• 示例完整度（30%）：能给出 dev/build/test/lint/typecheck 等脚本

常见错误：

• 一个 script 堆砌过多命令，难以调试
• 使用平台特定命令导致 Windows/Mac 行为不一致
• 脚本名称随意，新成员无法理解

延伸追问：

• 如果项目同时支持 csr 和 ssr，scripts 如何组织？
• npm run 和 npx 在 scripts 里有什么区别？

相关题目：

• FB-21-EN-A-009 团队级项目模板设计
• FB-21-EN-A-012 Git Hooks 自动化检查

参考资源：

• npm scripts 文档
• corepack 文档

口头回答版：

package.json 里的 scripts 是项目入口面板，命名要语义清晰，比如 dev、build、test、lint。可以用冒号做命名空间如 test:unit。每个脚本职责单一，复杂流程用 && 组合。要注意跨平台，别用 rm -rf，用 rimraf。README 里把最常用的几条写清楚。

---

FB-21-CO-B-033：语义化版本控制（SemVer）如何影响开发者体验？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、npm、版本管理、开发者体验 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请解释 SemVer 的基本规则，并说明它对依赖管理和开发者体验的影响。

参考答案：

核心要点：SemVer 通过 MAJOR.MINOR.PATCH 让依赖变更的影响范围可预期，是前端生态协作和自动化升级的基础。

详细解释：

1. MAJOR：不兼容的 API 变更；MINOR：向后兼容的功能新增；PATCH：向后兼容的问题修复。
2. 对 DX 的影响：可预期性、自动化安全更新、降低信任成本、便于回滚决策。
3. 范围符号：^1.2.3 允许 MINOR/PATCH；~1.2.3 只允许 PATCH；精确锁定。

最佳实践：

• 库发布严格遵循 SemVer，并在 CHANGELOG 中说明 BREAKING CHANGE。
• 团队约定统一使用 ^ 或锁版本策略。
• 结合 lock 文件和 Dependabot/Renovate 自动化依赖更新。

评分维度：

• 规则理解（40%）：能准确解释 MAJOR/MINOR/PATCH 含义
• 影响分析（35%）：能说明可预期性、自动化、信任成本、回滚
• 范围符号（25%）：能区分 ^、~、精确版本

常见错误：

• 认为版本号只是递增数字，忽略语义约定
• 在 MINOR 版本中引入破坏性变更
• 不维护 CHANGELOG，升级时只能靠 diff 猜测

延伸追问：

• 如果一个依赖从 0.x 升级到 1.0.0，应该注意什么？
• Monorepo 内部包使用 workspace:* 还是 SemVer 范围更好？

相关题目：

• FB-21-CO-B-003 Monorepo 与 Multirepo 差异
• FB-21-EN-P-049 Monorepo 版本发布自动化

参考资源：

• SemVer 官方规范
• npm semver 文档

口头回答版：

SemVer 就是主版本、次版本、修订号的约定。主版本变表示不兼容，次版本加功能，修订号修 bug。它让开发者看到版本号就知道升级风险，工具也能自动更新 patch 和小版本。团队里要统一用 ^ 还是锁版本，发布库时要写清楚 breaking change。

---

FB-21-EN-B-034：.editorconfig 的作用是什么？前端项目中通常如何配置？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、代码质量、编辑器配置、开发者体验 出现频率：低频 预计回答时长：2-3 分钟

题目描述： 请说明 .editorconfig 在前端工程中的作用，并给出一个适用于前端团队的典型配置。

参考答案：

核心要点：.editorconfig 跨编辑器统一缩进、换行符、编码等基础格式，减少因编辑器差异导致的无意义 diff 和风格争论。

详细解释：

1. 解决问题：Tab vs Space、CRLF vs LF、编码不一致、行尾空格。
2. 典型配置：root = true、charset = utf-8、end_of_line = lf、indent_style = space、indent_size = 2、insert_final_newline = true、trim_trailing_whitespace = true。
3. 与 Prettier 关系：.editorconfig 是编辑时约定，Prettier 是保存/提交时强制格式化；Prettier 会读取部分 editorconfig 配置。

最佳实践：

• 每个项目根目录放置 .editorconfig，并设置 root = true。
• 与 Prettier、ESLint 配合使用。
• 针对 Markdown、YAML、JSON 等做差异化配置。

评分维度：

• 作用理解（40%）：能说明跨编辑器统一格式、减少无意义 diff
• 配置能力（35%）：能写出 charset、end_of_line、indent_style 等关键项
• 工具协同（25%）：能说明与 Prettier 的关系

常见错误：

• 认为 .editorconfig 可以替代 Prettier 或 ESLint
• 不设置 root = true，导致父目录配置意外覆盖
• 忽略 YAML、Markdown 等文件类型

延伸追问：

• 如果团队成员使用不同编辑器，.editorconfig 如何生效？
• .editorconfig 和 .gitattributes 在换行符管理上如何分工？

相关题目：

• FB-21-CO-B-004 ESLint 与 Prettier 分工
• FB-21-SC-A-014 编辑器配置一致性

参考资源：

• EditorConfig 官方文档
• Prettier - EditorConfig

口头回答版：

.editorconfig 用来统一不同编辑器的格式，比如缩进用空格、换行符用 LF、文件编码 utf-8。典型配置会设 root=true、space、indent_size 2。它和 Prettier 是配合关系，Prettier 会读取部分 editorconfig 设置，但主要格式化还是 Prettier 做。

---

FB-21-CO-B-035：什么是“约定优于配置”？在前端工程中有哪些典型例子？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、开发者体验、设计模式、脚手架 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请解释“约定优于配置”的思想，并列举前端工程中的典型应用。

参考答案：

核心要点：约定优于配置是指工具通过内置合理默认约定减少显式配置，只在特殊需求时覆盖默认行为，从而降低上手成本和维护负担。

详细解释：

1. 核心思想：默认提供最佳实践约定，按约定组织代码即可运行，特殊需求再配置。
2. 典型例子：Next.js 文件路由、Nuxt.js 自动注册组件、Vite 默认 TS/CSS 支持、ESLint 共享配置、Husky .husky/ 目录自动注册。
3. trade-off：优点降低认知负担、统一实践；风险约定不透明时难以覆盖、过度约定限制灵活性。

最佳实践：

• 团队级脚手架内置清晰约定，并在文档中说明。
• 约定要配合可覆盖机制，不能变成黑盒。
• 约定变更时提供 codemod 或迁移脚本。

评分维度：

• 概念准确性（40%）：能清晰解释约定优于配置
• 举例能力（40%）：能举出 Next.js、Nuxt.js、Vite 等至少两个例子
• 权衡意识（20%）：能说明优点和潜在风险

常见错误：

• 把约定优于配置等同于“零配置”，忽略可覆盖性
• 认为约定会限制所有灵活性，全盘否定

延伸追问：

• 你们团队脚手架用了哪些约定？踩过什么坑？
• 业务需求与默认约定冲突时如何处理？

相关题目：

• FB-21-EN-B-002 前端脚手架解决的问题
• FB-21-EN-A-009 团队级项目模板设计

参考资源：

• Ruby on Rails - Convention over Configuration
• Next.js Routing

口头回答版：

约定优于配置就是工具给你一套默认最佳实践，按约定写代码就行，不用配很多东西。比如 Next.js 里 pages/index.tsx 自动是首页路由，Vite 默认支持 TS 和 CSS。好处是上手快、团队统一；但要注意约定要透明，特殊需求能覆盖。

---

FB-21-EN-B-036：前端项目的 README 应该包含哪些关键信息？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、文档、开发者体验、团队协作 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请说明一个高质量前端项目 README 应包含的核心模块，并解释它们分别服务哪些开发者角色。

参考答案：

核心要点：README 是新成员与项目的第一次交互，应在 5 分钟内让开发者完成环境准备、安装依赖、本地启动和常见操作；内容分层，先满足“跑起来”，再满足“深入理解”。

详细解释：

1. 必备模块：项目简介、环境要求、快速开始、目录结构、常用脚本、环境变量。
2. 进阶模块：架构说明、开发规范、部署发布、故障排查。
3. 服务角色：新成员看快速开始和目录结构；日常开发者看脚本和环境变量；维护者看架构和部署。

最佳实践：

• 快速开始命令做成可复制粘贴的代码块。
• 使用徽章展示构建状态、版本、文档链接。
• README 与真实代码保持同步，定期检查过期内容。

评分维度：

• 模块覆盖（40%）：能列出项目简介、环境要求、快速开始、目录结构、脚本、环境变量
• 角色意识（30%）：能说明不同内容服务新成员、开发者、维护者
• 实践细节（30%）：能提到代码块、徽章、同步更新

常见错误：

• README 只有项目名，没有快速开始步骤
• 命令已过时，新人按 README 无法启动
• 把 README 写成完整设计文档，重点不突出

延伸追问：

• 如果项目依赖多个后端服务，README 如何说明本地联调？
• 大型 Monorepo 根目录 README 应放什么？每个包是否还要 README？

相关题目：

• FB-21-CO-B-008 内部开发者文档
• FB-21-SC-P-023 新成员 onboarding

参考资源：

• Awesome README
• Diátaxis 文档框架

口头回答版：

README 要让人 5 分钟内跑起来。核心包括项目简介、环境要求、快速开始命令、目录结构、常用脚本、环境变量。对新成员要快速上手；对维护者要有架构说明、部署方式、故障排查。命令要写成可复制粘贴的代码块，并和代码保持同步。

---

FB-21-CO-B-037：什么是开发者门户（Developer Portal）？它和文档站点有什么区别？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：开发者体验、平台工程、文档、开发者门户 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请解释内部开发者门户（IDP）的概念，并说明它与普通文档站点的核心区别。

参考答案：

核心要点：开发者门户是面向工程师的内部平台入口，不仅聚合文档，还提供自助服务、工具集成、度量看板和治理规则；文档站点只是门户的内容子集。

详细解释：

1. 核心能力：服务目录、自助服务（创建项目、申请权限、开通环境）、文档与示例、度量看板、治理与标准。
2. 与文档站点区别：文档站点目标是传递知识，门户目标是提升工程效能；文档只读，门户可操作；门户数据自动同步代码、CI、监控。
3. 典型工具：Backstage、Port、OpsLevel。

最佳实践：

• 门户数据尽量从源码和平台自动同步，避免手工维护。
• 先解决一个高频痛点，再逐步扩展。
• 明确每个模块的 Owner，避免信息孤岛。

评分维度：

• 概念理解（40%）：能说明开发者门户是面向工程师的内部平台入口
• 区别分析（35%）：能从目标、交互、数据、范围对比文档站点
• 能力举例（25%）：能举出服务目录、自助服务、度量看板等能力

常见错误：

• 把开发者门户等同于文档站点或 Wiki
• 认为门户只是技术展示，忽略自助服务和治理
• 追求大而全，维护成本过高

延伸追问：

• 你们团队内部有没有类似门户？解决了什么问题？
• 开发者门户数据如何与代码仓库、CI、监控同步？

相关题目：

• FB-21-SD-P-017 内部开发者门户设计
• FB-21-CO-B-008 内部开发者文档

参考资源：

• Backstage 官方文档
• Gartner - IDP

口头回答版：

开发者门户是面向工程师的内部平台入口，不只是文档。它通常有服务目录、自助创建项目、权限申请、度量看板、技术标准等。文档站点只是门户的一部分。门户强调可操作和自动同步数据，比如直接从代码仓库拉取服务信息。

---

FB-21-EN-B-038：CI/CD 的基本概念是什么？它如何影响开发者体验？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、CI/CD、开发者体验、自动化 出现频率：高频 预计回答时长：3-5 分钟

题目描述： 请解释 CI（持续集成）和 CD（持续交付/部署）的基本概念，并说明一个良好的 CI/CD 流程如何提升开发者体验。

参考答案：

核心要点：CI/CD 通过自动化构建、测试和交付把代码变更快速可靠地推向用户；好的 CI/CD 让开发者专注于编码，而不是手工部署和等待验证。

详细解释：

1. CI：开发者频繁合并代码到主干，每次合并自动触发构建、lint、类型检查、单元测试，快速反馈回归问题。
2. CD 两种含义：Continuous Delivery 自动准备发布但需人工审批；Continuous Deployment 测试通过后自动部署生产。
3. 对 DX 影响：减少手动操作、快速反馈、降低发布焦虑、可追溯性。
4. 前端典型流程：PR 阶段安装→lint→typecheck→unit test→build→preview deploy；合并后构建→上传→灰度→全量。

最佳实践：

• CI 失败时给出清晰错误日志和修复建议。
• 使用 preview deploy 让 Reviewer 直接看到改动效果。
• 把耗时任务分层，先跑快速门禁，再跑重任务。

评分维度：

• 概念理解（40%）：能区分 CI、持续交付、持续部署
• 流程描述（30%）：能描述 PR 阶段和合并后的典型流程
• DX 影响（30%）：能说明减少手动操作、快速反馈、降低发布焦虑

常见错误：

• 把 CI 和 CD 混为一谈
• 认为 CI/CD 只是运维的事，与前端无关
• CI 失败信息不清晰，开发者反复猜测原因

延伸追问：

• 如果 CI 经常 flaky，会对团队产生什么影响？
• 前端项目如何在 CI 中做视觉回归测试？

相关题目：

• FB-21-EN-A-015 CI pipeline 反馈速度
• FB-21-CP-R-026 CI 反馈时间优化

参考资源：

• Martin Fowler - Continuous Integration
• GitLab CI/CD 文档

口头回答版：

CI 是持续集成，代码合并后自动跑构建、lint、测试；CD 是持续交付或部署，把代码自动发布。好的 CI/CD 让开发者不用手动打包上传，PR 阶段就能知道有没有问题，发布也更放心。前端典型流程是 PR 时跑 lint、测试、构建和预览部署，合并后自动发布。

---

进阶题（9 道）

FB-21-EN-A-039：如何设计前端项目的错误监控与告警体系？

题型：工程化题 / 场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、可观测性、错误监控、开发者体验 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请设计一套前端错误监控与告警体系，说明需要采集哪些数据、如何分级告警，以及如何让开发者快速定位问题。

参考答案：

核心要点：前端错误监控应以“快速发现、快速定位、快速止损”为目标，覆盖运行时错误、资源加载、接口异常、性能异常和业务异常，并通过 Source Map 还原真实堆栈。

详细解释：

1. 采集数据：JS 运行时错误、资源加载失败、接口异常、性能异常、自定义业务错误。
2. 分级告警：P0 立即响应（核心流程大量报错）、P1 当日处理（非核心功能不可用）、P2 排期处理（低频错误或性能退化）。
3. 快速定位：Source Map 还原、错误关联用户/路由/版本/浏览器、聚合相似错误、IM/工单集成。
4. 工具：Sentry、Fundebug、ARMS、腾讯灯塔。

最佳实践：

• 错误采样率按环境配置，开发 100%，生产合理采样。
• 对第三方脚本错误过滤和脱敏。
• 建立 On-call 轮值和错误复盘机制。

评分维度：

• 数据采集（35%）：能覆盖 JS 错误、资源、接口、性能、业务错误
• 告警分级（30%）：能按 P0/P1/P2 分级并说明响应时效
• 定位能力（35%）：能说明 Source Map、错误关联、聚合、告警渠道

常见错误：

• 只监控 JS 报错，忽略资源和接口异常
• 告警阈值过严导致告警疲劳，过松导致漏报
• 没有 Source Map，线上报错堆栈无法还原

延伸追问：

• 如何处理第三方脚本导致的跨域错误？
• 错误采样率过高导致成本失控，如何平衡？

相关题目：

• FB-21-SD-P-056 前端错误追踪与诊断平台
• FB-21-SD-R-061 前端研发效能数据中台

参考资源：

• Sentry 前端监控指南
• Web Vitals

口头回答版：

前端错误监控要覆盖 JS 报错、资源加载失败、接口异常、性能异常和业务自定义错误。告警要分级，P0 是核心流程大量报错必须立即处理，P1 当天处理，P2 排期。定位问题靠 Source Map 还原堆栈、关联用户和版本信息、聚合相似错误。工具可以用 Sentry 或自研 SDK，还要注意采样率和隐私脱敏。

---

FB-21-SC-A-040：新工具引入团队时，如何制定推广策略？

题型：场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、团队协作、开发者体验、软技能 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 假设你发现一个新工具能显著提升效率，但团队已有成熟工作流。请说明你会如何制定推广策略，让团队平稳接受并落地。

参考答案：

核心要点：新工具推广要遵循“先验证价值、再建立共识、然后渐进落地、持续收集反馈”的节奏，避免强制切换和一刀切。

详细解释：

1. 验证价值：小范围试点，收集量化数据，识别风险。
2. 建立共识：技术分享、RFC、找 early adopters 作为内部倡导者。
3. 渐进落地：新项目试用，存量项目逐步迁移，提供脚手架、文档、codemod。
4. 持续反馈：建立反馈渠道，根据痛点迭代，庆祝 early win。

最佳实践：

• 不要只推广工具，要推广“解决问题的方式”。
• 为工具指定明确 Owner，负责维护和答疑。
• 制定退出策略：效果不好时如何回滚。

评分维度：

• 策略完整性（40%）：能覆盖验证、共识、落地、反馈四个阶段
• 风险意识（30%）：能提到兼容性、学习成本、维护责任、回滚策略
• 协作意识（30%）：能说明技术分享、RFC、early adopters、反馈渠道

常见错误：

• 仅凭个人喜好强制团队切换
• 忽视学习成本和文档，导致成员抵触
• 没有量化收益，无法说服管理层

延伸追问：

• 如果试点效果很好，但核心成员强烈反对，怎么办？
• 新工具和旧方案并行期间，如何保证代码一致性？

相关题目：

• FB-21-SS-P-020 推动统一 DX 平台
• FB-21-CP-P-050 评估新技术引入

参考资源：

• Technology Adoption Curve
• Google - How to introduce new tools

口头回答版：

新工具推广不能硬推。先在小范围试点跑数据；然后通过技术分享、RFC、找 early adopters 建立共识；再在新项目试用，存量项目逐步迁移，提供文档和迁移脚本；最后持续收反馈迭代。要讲清楚解决了什么问题，并指定 Owner 和回滚策略。

---

FB-21-PE-A-041：如何优化前端项目的依赖安装速度？

题型：性能优化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、性能优化、pnpm、npm、依赖管理 出现频率：高频 预计回答时长：5-8 分钟

题目描述： 请分析前端项目 npm install 慢的常见原因，并给出至少 5 个可落地的优化手段。

参考答案：

核心要点：依赖安装慢通常由网络、依赖体积、解析算法和 I/O 导致；优化应从包管理器选择、缓存策略、依赖精简和镜像源等多方面入手。

详细解释：

1. 常见原因：网络慢、依赖过多、版本范围宽泛、lock 文件冲突、幽灵依赖。
2. 优化手段：换 pnpm、配置镜像源、启用 CI 缓存、精简依赖、锁定版本、按需安装 --frozen-lockfile、dev/prod 依赖分组。
3. 度量：记录安装耗时、分析 node_modules 体积、用 pnpm why 分析依赖来源。

最佳实践：

• 统一包管理器并锁定版本（corepack / packageManager）。
• 定期审计依赖，pnpm audit + depcheck。
• CI 中分层缓存 lock 文件、store、node_modules。

评分维度：

• 原因分析（30%）：能说出网络、依赖体积、版本解析、lock 冲突等原因
• 优化手段（40%）：能给出换包管理器、镜像、缓存、精简、锁定版本等手段
• 度量能力（30%）：能说明如何记录安装耗时和分析依赖体积

常见错误：

• 一慢就删 node_modules 重装，不解决根本问题
• 不提交 lock 文件，导致安装结果不一致
• CI 中不缓存依赖，每次从零安装

延伸追问：

• pnpm 的 content-addressable store 为什么比 npm 快？
• 如果一个依赖体积很大但功能必需，如何减少影响？

相关题目：

• FB-21-EN-A-010 pnpm workspace + Turborepo
• FB-21-PE-A-011 构建性能优化

参考资源：

• pnpm 性能优势
• npm install 优化

口头回答版：

安装慢常见原因有网络慢、依赖太多、版本解析复杂、lock 文件冲突。优化可以换 pnpm，配镜像源，CI 里缓存 store 和 node_modules，精简依赖，锁定版本用 lock 文件。还要统一包管理器，定期审计依赖。

---

FB-21-EN-A-042：如何实现前端组件库文档的自动化生成？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Storybook、文档、组件库、自动化 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请说明如何通过自动化手段降低组件库文档维护成本，并列举可生成的文档内容和典型工具。

参考答案：

核心要点：组件库文档自动化是从源码、类型、注释、示例和测试中自动提取信息生成文档，减少人工维护，保证文档与代码同步。

详细解释：

1. 可生成内容：API 表格、使用示例、类型定义、CHANGELOG、Design Token。
2. 典型工具：Storybook、VitePress/Docusaurus、TypeDoc、react-docgen、Chromatic。
3. 自动化流程：PR 阶段校验文档是否更新；合并后自动构建部署；发布时自动生成迁移指南和 CHANGELOG。

最佳实践：

• 文档与源码同仓库，随版本一起发布。
• 用 JSDoc/TSDoc 规范注释。
• 示例代码必须可运行或经过测试。

评分维度：

• 自动化内容（35%）：能说出 API、示例、类型、CHANGELOG、Token 等可生成内容
• 工具选择（35%）：能列举 Storybook、TypeDoc、react-docgen 等工具
• 流程设计（30%）：能说明 PR 校验、自动构建部署、发布时生成迁移指南

常见错误：

• 文档和源码分离，导致长期不同步
• 自动生成后完全不人工审核
• 示例代码不可运行，误导使用者

延伸追问：

• 如何保证自动生成的 API 文档对非 TS 项目也有效？
• 如果组件支持多技术栈，文档如何组织？

相关题目：

• FB-21-CO-B-008 内部开发者文档
• FB-21-SD-R-029 组件/文档/示例一体化工具链

参考资源：

• Storybook Docs
• TypeDoc 官方文档

口头回答版：

组件库文档自动化可以从源码里提取信息生成 API 表、示例、类型、CHANGELOG。常用工具：Storybook 做交互示例，TypeDoc 提取 props，VitePress 搭站点。流程上 PR 时校验文档，合并后自动部署，发布时自动生成迁移指南。关键是文档和代码同仓库，示例要能跑。

---

FB-21-SC-A-043：跨团队协作时，如何管理 API 文档以提升 DX？

题型：场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、团队协作、API 文档、开发者体验 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 在前后端或多前端团队协作中，API 文档经常过时或不一致。请设计一套方案，让 API 文档成为提升开发者体验的工具而非负担。

参考答案：

核心要点：API 文档管理应以“契约即代码”为核心，通过 OpenAPI/Swagger、Mock 服务、自动化校验和版本化管理，让文档与实现保持一致并可直接用于开发。

详细解释：

1. 契约驱动：用 OpenAPI / GraphQL Schema 定义接口，契约作为前后端共同标准。
2. 自动生成与同步：后端生成 OpenAPI JSON，前端用它生成 TS 类型和请求函数，文档站点自动渲染 Swagger UI / Redoc。
3. Mock 与联调：基于契约的 Mock 服务让前端并行开发；契约变更时通知消费者。
4. 版本与变更管理：API 版本化、破坏性变更审批、CHANGELOG 自动记录。

最佳实践：

• 把契约文件纳入 CI 校验，实现与文档不一致时阻断合并。
• 建立 API 变更通知机制。
• 提供 TypeScript 类型生成，让前端编译期发现不匹配。

评分维度：

• 契约驱动（35%）：能说明 OpenAPI/Schema 作为前后端共同标准
• 自动化能力（30%）：能说明自动生成文档、类型、Mock
• 变更管理（35%）：能说明版本化、变更通知、CI 校验

常见错误：

• API 文档用 Word 或 Wiki 维护，无法自动校验
• 后端接口改了但不更新文档
• 没有版本管理，一次变更影响所有消费者

延伸追问：

• 如果后端不愿意写 OpenAPI，你如何推动？
• 前后端对字段命名不一致时，契约如何解决？

相关题目：

• FB-21-SD-P-017 内部开发者门户
• FB-21-SD-R-029 组件/文档/示例一体化工具链

参考资源：

• OpenAPI Specification
• MSW 文档

口头回答版：

跨团队协作要用契约驱动，OpenAPI 或 GraphQL Schema 就是前后端共同标准。后端从代码生成 OpenAPI，前端用它生成 TS 类型和请求函数，文档站点自动渲染。还要提供基于契约的 Mock，让前端能并行开发。API 要版本化，破坏性变更通知消费者，CI 里校验实现和文档是否一致。

---

FB-21-EN-A-044：如何实现前端项目的自动升级提醒？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、npm、自动化、开发者体验 出现频率：低频 预计回答时长：5-8 分钟

题目描述： 请说明如何在前端项目中实现依赖、脚本和配置的自动升级提醒，让团队及时了解可用更新而不被打断。

参考答案：

核心要点：自动升级提醒应遵循“及时告知、不强制打断、提供决策信息”的原则，通过 CLI 检查、CI 报告、Bot 通知等方式让团队掌握升级机会。

详细解释：

1. 依赖升级提醒：npm outdated、pnpm outdated、Dependabot/Renovate 自动 PR、npm-check-updates。
2. 配置和脚本升级：脚手架模板版本号写入项目元数据，CLI doctor 命令对比差异。
3. 提醒策略：本地启动时显示可升级项、每周生成健康报告、安全/MAJOR 变更高优先级。
4. 避免打扰：允许忽略某些包提醒，区分建议升级和必须升级，提供一键升级脚本或 codemod。

最佳实践：

• 安全更新必须提醒并设定修复期限。
• MAJOR 升级附带迁移指南和风险评估。
• 与内部开发者门户集成，形成统一视图。

评分维度：

• 覆盖范围（35%）：能覆盖依赖、配置、脚本三类升级提醒
• 工具选择（30%）：能提到 Dependabot、Renovate、npm-check-updates、自定义 CLI
• 策略设计（35%）：能说明分级提醒、避免打扰、提供迁移方案

常见错误：

• 每次启动都弹大量升级提示，开发者习惯性忽略
• 只提醒不给出迁移方案，导致升级停滞
• 对所有更新一视同仁，没有优先级

延伸追问：

• 如果某个依赖长期不升级，如何度量其带来的风险？
• 自动升级 PR 频繁失败，如何减少维护成本？

相关题目：

• FB-21-CO-B-033 SemVer 对 DX 影响
• FB-21-EN-P-054 依赖安全扫描与自动修复

参考资源：

• Dependabot 文档
• Renovate 文档

口头回答版：

自动升级提醒要及时但不能太打扰。依赖可以用 Dependabot 或 Renovate 自动提 PR，本地用 npm outdated 检查；配置和脚本可以通过脚手架 doctor 命令对比模板版本。提醒要分优先级，安全更新和 major 版本必须处理，其他可以建议。还要给迁移指南或 codemod。

---

FB-21-CP-A-045：如何在代码规范严格度与开发效率之间取得平衡？

题型：综合开放题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、代码质量、团队协作、开发者体验 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 过于严格的代码规范可能拖慢开发，过于宽松又会导致代码质量下降。请说明你会如何为团队找到合适的平衡点。

参考答案：

核心要点：平衡点应随团队成熟度、项目阶段和业务节奏动态调整；规范的价值在于减少低级错误和沟通成本，而非增加 bureaucracy。

详细解释：

1. 分阶段推进：新项目用社区成熟配置；成长期按痛点逐步加自定义规则；成熟期重点转向自动化修复和度量。
2. 规则分级：强制 error（会导致 Bug）、建议 warn（风格类初期可 warn）、关闭 off（争议大收益低）。
3. 减少摩擦：提供 --fix 自动修复、规则变更走 RFC、允许紧急情况 --no-verify 但事后补齐。
4. 数据驱动：统计规则触发频率，收集开发者满意度，调整过度严格项。

最佳实践：

• 规范制定要团队共同参与。
• 优先解决真实痛点，而非追求完美代码。
• 把规范解释写进文档，新人知道“为什么”。

评分维度：

• 平衡思路（40%）：能说明随团队成熟度动态调整、规则分级
• 落地策略（30%）：能提到自动修复、RFC、紧急情况处理
• 数据意识（30%）：能说明统计规则触发频率、收集团队反馈

常见错误：

• 为规范而规范，规则过多且与实际痛点无关
• 一次性开启所有严格规则，导致大量报错
• 规范制定不透明，团队成员不理解

延伸追问：

• 如果团队对某个规则争论很大，你如何决策？
• 规范执行导致紧急需求延期，如何向业务方解释？

相关题目：

• FB-21-CO-B-004 ESLint 与 Prettier 分工
• FB-21-EN-A-012 Git Hooks 自动化检查

参考资源：

• ESLint 规则配置
• Google TypeScript Style Guide

口头回答版：

规范和效率要动态平衡。新项目先用社区成熟配置，别自己造规则；然后按痛点逐步加。规则分三级：会导致 bug 的强制报错，风格类的先 warn 再转 error，争议大的关掉。要提供自动修复，规则变更走 RFC，还要统计数据看哪些规则老触发。关键是让团队参与制定。

---

FB-21-EN-A-046：前端项目中的环境变量管理有哪些最佳实践？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Vite、Webpack、环境变量、安全 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 请说明前端项目中环境变量的分类、命名规范、注入方式和安全注意事项。

参考答案：

核心要点：前端环境变量应区分构建时与运行时、公共与私有，通过命名约定和模板文件保证本地可启动、线上不泄露敏感信息。

详细解释：

1. 分类：构建时变量（API 基地址、CDN 路径、功能开关）、运行时变量（SSR 注入 window.ENV）、公共变量（VITE_/NEXT_PUBLIC_ 前缀）、私有变量（仅在 Node/构建工具侧使用）。
2. 命名与组织：用 env.example 列出必需变量；按环境分 .env、.env.local、.env.production、.env.development。
3. 注入方式：Vite 用 import.meta.env、CRA 用 process.env.REACT_APP_、Next.js 分客户端/服务端、Webpack 用 DefinePlugin。
4. 安全注意：不把密钥暴露给客户端；.env* 纳入 .gitignore；CI 中用 secrets 管理。

最佳实践：

• 提供 env.example 并在 README 中说明配置方式。
• 启动时校验必需变量是否缺失，给出明确报错。
• 敏感变量通过 CI secrets 或密钥管理服务注入。

评分维度：

• 分类清晰（40%）：能区分构建时/运行时、公共/私有变量
• 注入方式（30%）：能说明 Vite/CRA/Next.js/Webpack 的注入方式
• 安全意识（30%）：能说明敏感变量不进入 bundle、用 secrets 管理

常见错误：

• 把服务端密钥直接注入前端 bundle
• 不提交 env.example，新人不知道要配哪些变量
• 环境变量命名混乱，不同项目规则不一致

延伸追问：

• 如果需要在部署后动态修改 API 地址，应该怎么做？
• 多环境（dev/test/staging/prod）下如何组织 .env 文件？

相关题目：

• FB-21-CO-B-007 本地开发环境一致性
• FB-21-EN-A-009 团队级项目模板设计

参考资源：

• Vite 环境变量
• Next.js Environment Variables

口头回答版：

前端环境变量要分构建时和运行时、公共和私有。公共变量通常要加 VITE_ 或 NEXT_PUBLIC_ 前缀才能在客户端用。要提供 env.example 说明需要配什么，本地用 .env.local 覆盖但不提交。敏感信息比如密钥绝对不能进前端 bundle，要用 CI secrets 注入。

---

FB-21-SC-A-047：如何设计一个有效的内部技术分享机制？

题型：场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：团队协作、软技能、知识传承、开发者体验 出现频率：低频 预计回答时长：5-8 分钟

题目描述： 请设计一套内部技术分享机制，既能促进知识传承，又不会给分享者和参与者造成过大负担。

参考答案：

核心要点：技术分享机制应围绕“低门槛、高频次、可复用、有反馈”设计，把分享从偶发活动变成团队日常知识流动的管道。

详细解释：

1. 形式分层：闪电分享（5-10 分钟）、专题分享（30-60 分钟）、代码走读/设计评审、文档沉淀。
2. 降低门槛：提供分享模板、允许多种形式、建立选题池。
3. 激励机制：纳入绩效或晋升参考、设立最佳分享奖、提供时间保障。
4. 反馈与复用：收集反馈、录屏或写纪要放入知识库、把高频问题转 FAQ。

最佳实践：

• 固定时间形成习惯，比如每周五下午。
• 分享主题贴近当前项目痛点。
• 鼓励新人分享 onboarding 困惑，促进文档改进。

评分维度：

• 形式设计（35%）：能设计闪电分享、专题分享、代码走读等分层形式
• 门槛与激励（35%）：能降低分享门槛并建立激励机制
• 复用与反馈（30%）：能说明文档沉淀、录屏、反馈收集

常见错误：

• 分享变成少数人的表演，大多数人只是听众
• 形式过于正式，准备成本高、频率低
• 分享后不沉淀，知识无法持续传播

延伸追问：

• 如果团队很忙，没人愿意花时间分享，你怎么推动？
• 如何度量技术分享对团队能力的实际提升？

相关题目：

• FB-21-CO-B-008 内部开发者文档
• FB-21-SC-P-023 新成员 onboarding

参考资源：

• Spotify 工程文化
• Diátaxis 文档框架

口头回答版：

内部技术分享要形式多样、门槛低。可以有每周 10 分钟闪电分享，每月一次专题，还有把代码 Review 变成学习机会。要提供模板、允许多种形式、建立选题池。分享后一定要沉淀成文档或视频，并收集反馈。还可以把分享纳入绩效认可，固定时间形成习惯。

---

深入题（9 道）

FB-21-SD-P-048：如何设计一个前端工程化度量平台？

题型：系统设计题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、可观测性、效能度量、平台工程 出现频率：中频 预计回答时长：10-15 分钟

题目描述： 请设计一个面向前端团队的工程化度量平台，说明需要采集哪些数据、核心指标、架构模块和落地挑战。

参考答案：

补充说明：

在实际落地 设计一个前端工程化度量平台 时，建议结合 前端工程化、可观测性、效能度量 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 核心要点：前端工程化度量平台通过采集代码、构建、CI、发布和运行时数据，帮助团队客观评估 DX 和工程效能，并指导改进方向。

详细解释：

1. 数据采集：代码数据、构建数据、CI 数据、发布数据、运行时数据、满意度数据。
2. 核心指标：DORA 四指标、构建效能、质量指标、体验指标。
3. 架构模块：数据接入层、数据仓库、计算引擎、展示层、治理层。
4. 落地挑战：数据分散、指标定义不统一、易被误解为考核、短期收益不明显。

最佳实践：

• 从 3-5 个核心指标开始，避免指标泛滥。
• 明确度量目的：改进流程，而非评价个人。
• 数据可视化要支持下钻。

评分维度：

• 数据采集（30%）：能覆盖代码、构建、CI、发布、运行时、满意度数据
• 指标设计（30%）：能列出 DORA、构建效能、质量、体验指标
• 架构能力（25%）：能说明接入层、数据仓库、计算引擎、展示层、治理层
• 挑战意识（15%）：能提到数据分散、指标定义、度量误用、长期投入

常见错误：

• 追求指标数量，导致团队无所适从
• 把度量结果与个人绩效挂钩，破坏信任
• 只展示数据，不给出改进建议

延伸追问：

• 如何保证不同项目、不同技术栈的数据口径一致？
• 如果团队质疑某个指标，你如何解释其合理性？

相关题目：

• FB-21-CP-P-021 DORA 与 SPACE
• FB-21-SD-R-061 前端研发效能数据中台

参考资源：

• DORA Metrics
• SPACE Framework

口头回答版：

前端工程化度量平台要采集代码、构建、CI、发布、运行时和满意度数据。核心指标可以用 DORA 四指标，加上构建时间、缓存命中率、缺陷密度、开发者 NPS。架构上分接入层、数据仓库、计算引擎、展示层和治理层。落地时不要一上来做很多指标，先从 3-5 个开始，而且要明确是改进流程不是考核个人。

---

FB-21-EN-P-049：Monorepo 中如何实现版本发布自动化？

题型：工程化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Monorepo、版本管理、自动化、CI/CD 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请说明 Monorepo 场景下，如何设计一套自动化的版本发布流程，包括版本号确定、Changelog 生成和发布触发机制。

参考答案：

核心要点：Monorepo 版本发布自动化的核心是基于 changesets 的语义化版本管理，通过工具追踪每个包变更、计算版本号、生成 Changelog，并在 CI 中完成发布。

详细解释：

1. 变更追踪：PR 时附带 changeset 文件说明变更类型和影响包；工具如 Changesets、Beachball、Rush、Lerna。
2. 版本号计算：根据 changeset 自动 bump 版本，处理依赖传递；区分 fixed 和 independent 模式。
3. Changelog 生成：从 changeset 和 Conventional Commits 自动生成，含变更摘要和迁移指南。
4. 发布触发：合并 Version Packages PR 后自动发布，或 main 分支满足条件自动发布。
5. 安全与回滚：发布前跑全量测试和构建，用 --dry-run 预览，保留历史版本支持回滚。

最佳实践：

• 强制 PR 必须包含 changeset。
• 预发布通道（alpha/beta/rc）用于大版本灰度。
• 发布后自动在内部频道通知消费者。

评分维度：

• 变更追踪（30%）：能说明 changeset 机制及常用工具
• 版本计算（25%）：能说明 major/minor/patch 计算和依赖传递
• 发布流程（25%）：能说明 Changelog 生成、CI 触发、发布命令
• 安全回滚（20%）：能提到 dry-run、预发布通道、回滚策略

常见错误：

• 没有 changeset 机制，靠人工记版本导致漏发或错发
• 所有包强制统一版本，导致无关包也被 bump
• 发布后没有通知机制

延伸追问：

• fixed 和 independent 版本模式各适合什么场景？
• 如果 changeset 写错了，发布前如何修正？

相关题目：

• FB-21-CO-B-003 Monorepo 与 Multirepo 差异
• FB-21-EN-A-010 pnpm workspace + Turborepo

参考资源：

• Changesets 文档
• Lerna 版本管理

口头回答版：

Monorepo 版本发布自动化一般用 changeset。PR 提交时附带 changeset 文件说明是 major、minor 还是 patch，工具自动算版本、生成 Changelog，CI 里自动发布。要处理包之间的依赖传递，选择 fixed 还是 independent 模式。发布前要 dry-run，还要有 alpha/beta 通道做灰度，发布后通知消费者。

---

FB-21-CP-P-050：如何评估一项新技术是否值得引入团队？

题型：综合开放题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、技术选型、团队协作、平台工程 出现频率：中频 预计回答时长：8-15 分钟

题目描述： 面对一项热门新技术，你会从哪些维度评估它是否适合引入团队？请给出可复用的评估框架。

参考答案：

核心要点：技术引入评估应围绕问题匹配度、技术成熟度、团队适配性、长期成本四个维度展开，用数据和试点替代直觉和 hype。

详细解释：

1. 问题匹配度：是否解决当前真正痛点、现有方案成本、收益是否可量化。
2. 技术成熟度：社区活跃度、生态完整性、稳定性、可替代性。
3. 团队适配性：学习曲线、维护能力、招聘影响。
4. 长期成本：迁移成本、运维成本、机会成本。
5. 评估框架：评分卡 1-5 分、小范围试点 2-4 周、写 RFC 明确收益风险回滚方案和 Owner。

最佳实践：

• 不为技术而技术，优先解决真实问题。
• 引入前先在非核心项目验证。
• 设定明确退出条件，试点不达预期及时止损。

评分维度：

• 维度完整性（40%）：能覆盖问题匹配、成熟度、团队适配、长期成本
• 评估方法（30%）：能说明评分卡、试点、RFC 等方法
• 风险意识（30%）：能提到迁移成本、维护成本、退出条件

常见错误：

• 因为社区热度高就引入，不考虑团队实际
• 只看短期收益，忽略长期维护成本
• 没有试点和回滚方案，直接全量推广

延伸追问：

• 如果新技术与现有技术栈冲突，你如何决策？
• 管理层不认可引入成本，你如何说服？

相关题目：

• FB-21-SC-A-040 新工具推广策略
• FB-21-CP-R-060 大型企业前端工具链标准化

参考资源：

• Technology Radar
• The Hype Cycle

口头回答版：

评估新技术要看四个维度：问题匹配度，是不是真痛点；技术成熟度，社区活不活跃、生态全不全；团队适配性，大家能不能快速上手、有没有人维护；长期成本，迁移和运维要花多少。可以用评分卡加小范围试点，写 RFC 明确收益和风险，还要设退出条件。

---

FB-21-PE-P-051：大型项目构建缓存失效的常见原因有哪些？如何应对？

题型：性能优化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、性能优化、构建性能、缓存、Monorepo 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请分析大型前端项目或 Monorepo 中构建缓存频繁失效的原因，并给出排查和优化策略。

参考答案：

核心要点：构建缓存失效会显著拖慢 CI 和本地开发；失效通常由输入不可控、配置未正确声明、非确定性输出或环境变化导致，需要系统化排查和精确声明 inputs/outputs。

详细解释：

1. 常见失效原因：inputs 未精确声明、绝对路径混入、环境变量变化、依赖版本漂移、非确定性输出、全局状态污染。
2. 排查方法：Turborepo dry-run 查看 hash、对比输入文件列表、检查产物是否含变化字符串、记录构建环境信息。
3. 优化策略：精确声明 inputs/outputs、将环境变量分稳定/易变、用内容 hash 替代时间戳、配置 deterministic module ids、定期清理远程缓存。

最佳实践：

• 本地和 CI 使用同一套缓存策略。
• 对关键任务建立缓存命中率监控。
• 新加环境变量或配置时评估是否影响缓存 hash。

评分维度：

• 原因分析（40%）：能说出 inputs、绝对路径、环境变量、依赖漂移、非确定性输出等原因
• 排查能力（30%）：能使用 dry-run、输入对比、产物分析等方法
• 优化策略（30%）：能说明精确声明 inputs/outputs、内容 hash、deterministic ids 等

常见错误：

• 不声明 inputs，默认全仓库文件参与 hash
• 把每次构建都变的 BUILD_ID 作为缓存输入
• 远程缓存被污染后不及时清理

延伸追问：

• Turborepo 和 Nx 在缓存 hash 计算上有何异同？
• 如果一个任务依赖网络请求结果，如何设计缓存策略？

相关题目：

• FB-21-EN-A-010 pnpm workspace + Turborepo
• FB-21-SD-R-027 Monorepo 远程缓存与任务调度

参考资源：

• Turborepo Caching
• Nx Caching

口头回答版：

构建缓存失效常见原因有：inputs 没精确声明、产物里有绝对路径或时间戳、环境变量每次变、依赖版本漂移、输出不稳定。排查时用 dry-run 看 hash 计算，对比输入文件，检查产物内容。优化要精确声明 inputs 和 outputs，用内容 hash 而不是时间戳，环境变量里只把必要的放进 hash，还要配 deterministic module ids。

---

FB-21-SD-P-052：如何设计一个可插拔的前端 CLI 工具？

题型：系统设计题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、CLI、Node.js、设计模式、开发者体验 出现频率：低频 预计回答时长：8-15 分钟

题目描述： 请设计一个可插拔的前端 CLI 工具，支持命令扩展、配置覆盖和插件生态，并说明核心架构和扩展机制。

参考答案：

核心要点：可插拔 CLI 应分离命令解析、配置合并、插件加载和业务执行四层，通过约定目录、配置文件和 npm 包三种方式支持扩展。

详细解释：

1. 核心架构：命令解析层（commander/yargs/oclif）、配置层（默认+项目+参数+环境变量）、插件层（内置/本地/npm）、执行层（pipeline + hooks）。
2. 扩展机制：命令扩展、Hook 机制（beforeRun/afterRun/onError）、Preset 机制、配置覆盖。
3. 插件加载顺序：内置插件 → 配置文件声明的插件 → 命令行指定的插件；每个插件暴露 apply(api) 方法。

最佳实践：

• 核心保持轻量，复杂功能通过插件实现。
• 提供清晰的插件开发文档和类型定义。
• 版本化插件 API，避免核心升级导致插件失效。

评分维度：

• 架构分层（35%）：能说明命令解析、配置、插件、执行四层
• 扩展机制（35%）：能说明命令扩展、hooks、preset、配置覆盖
• 生态设计（30%）：能说明插件加载顺序、类型定义、API 版本化

常见错误：

• 把所有功能写死在核心，无法扩展
• 插件 API 不稳定，每次核心升级都破坏插件
• 插件加载顺序不可控，导致冲突难以排查

延伸追问：

• 如何保证第三方插件的质量和安全性？
• CLI 插件与 Webpack/Vite 插件在设计上有什么异同？

相关题目：

• FB-21-EN-B-002 前端脚手架解决的问题
• FB-21-SD-R-025 可扩展的脚手架生态

参考资源：

• oclif 框架
• commander.js 文档

口头回答版：

可插拔 CLI 要分四层：命令解析、配置合并、插件加载、业务执行。插件可以通过命令扩展、hook 机制、preset 来扩展功能。核心要轻量，复杂能力交给插件。要定义稳定的插件 API，提供类型和文档，插件加载顺序要清晰，配置覆盖顺序也要明确。

---

FB-21-SS-P-053：如何建立可持续的技术债治理流程？

题型：软技能题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、技术债、团队协作、效能度量 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 技术债不可避免，但放任不管会拖慢团队。请设计一套可持续的技术债识别、记录、优先级排序和偿还流程。

参考答案：

核心要点：技术债治理应把“隐性的坑”变成“可见的清单”，通过统一登记、业务对齐、分期偿还和度量反馈，避免技术债无限累积。

详细解释：

1. 识别与记录：建立 Tech Debt Register，记录问题、影响、位置、建议方案；来源包括 Code Review、监控、自动化扫描、开发者反馈。
2. 优先级排序：影响范围、修复成本、风险等级、业务关联。
3. 偿还策略：随需求偿还、每个迭代预留 10-20% 专项时间、高风险模块暂停新增。
4. 度量与反馈：跟踪债务数量、平均年龄、偿还速度；纳入复盘和季度规划；定期清理过期债务。

最佳实践：

• 技术债登记要与业务方可见，争取资源支持。
• 避免用“重构”掩盖没有明确目标的工作。
• 每次偿还写清楚验收标准和验证方式。

评分维度：

• 流程完整性（40%）：能覆盖识别、记录、排序、偿还、度量
• 优先级方法（30%）：能说明影响范围、成本、风险、业务关联等排序维度
• 落地意识（30%）：能提到随需求偿还、专项时间、业务方沟通

常见错误：

• 技术债只停留在口头，没有书面记录
• 一次性想还清所有技术债，影响业务交付
• 把技术债当作“偷懒”借口，不控制新增

延伸追问：

• 如果业务方不理解技术债，你如何争取偿还时间？
• 如何判断某个技术债已经“还清”？

相关题目：

• FB-21-CP-A-045 规范严格度与效率平衡
• FB-21-SD-R-061 前端研发效能数据中台

参考资源：

• Martin Fowler - Technical Debt Quadrant
• Google - Manage Technical Debt

口头回答版：

技术债治理要建立登记表，把问题、影响、建议方案记下来。来源可以是 Code Review、监控、自动化扫描。优先级看影响范围、修复成本、风险、业务关联。偿还时可以随需求顺手改，也可以每个迭代留 10-20% 专项时间。还要跟踪债务数量、年龄、偿还速度，定期和业务方沟通争取资源。

---

FB-21-EN-P-054：如何实现前端依赖的安全扫描与自动化修复？

题型：工程化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、安全、依赖管理、自动化、CI/CD 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 请说明前端项目如何建立依赖安全扫描机制，包括漏洞发现、分级响应、自动修复和阻断策略。

参考答案：

核心要点：前端依赖安全扫描应嵌入开发生命周期，通过自动化工具持续发现漏洞，按严重等级响应，并在 CI 中对高危漏洞进行阻断。

详细解释：

1. 漏洞发现：npm audit、pnpm audit、Snyk、Dependabot、Trivy、OSV、SBOM。
2. 分级响应：Critical/High 立即修复并阻塞发布；Medium 规划修复；Low 评估后处理。
3. 自动修复：npm audit fix、Dependabot/Renovate 自动 PR、无法修复时提供替代方案。
4. 阻断策略：CI 中 pnpm audit --audit-level high 失败阻断；.snyk 策略文件对误报设置忽略期限；禁止未验证私有包。
5. 持续监控：订阅漏洞通知，定期生成安全报告。

最佳实践：

• 安全扫描嵌入每次 PR，而非只在发布前。
• 对安全升级 PR 优先 Review 和合并。
• 建立漏洞响应 On-call 机制。

评分维度：

• 扫描工具（30%）：能提到 npm audit、Snyk、Dependabot、Trivy、SBOM
• 分级响应（25%）：能按 Critical/High/Medium/Low 分级并说明响应时效
• 自动修复（25%）：能说明 audit fix、自动 PR、替代方案
• 阻断策略（20%）：能说明 CI 阻断、忽略策略、包来源控制

常见错误：

• 只在发布前扫描一次
• 对 audit 报告所有问题一视同仁，浪费资源
• 忽略间接依赖的安全风险

延伸追问：

• 如果某个高危漏洞没有可用补丁，你如何临时缓解？
• 如何防止供应链攻击（如恶意包、typo-squatting）？

相关题目：

• FB-21-EN-A-044 自动升级提醒
• FB-21-CP-P-050 评估新技术引入

参考资源：

• npm audit 文档
• Snyk 文档

口头回答版：

前端依赖安全要用工具持续扫描，比如 npm audit、Snyk、Dependabot。漏洞要分级，Critical 和 High 立即修并阻断发布，Medium 规划修，Low 评估后处理。自动修复可以用 audit fix 或 Dependabot 提 PR，修不了的给替代方案。CI 里要跑扫描，高危失败不允许合并，还要持续监控新漏洞。

---

FB-21-CP-P-055：如何度量前端团队的整体工程效能？

题型：综合开放题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、效能度量、团队协作、DORA 出现频率：高频 预计回答时长：8-15 分钟

题目描述： 请说明你会如何选择和组合指标，来客观度量前端团队的工程效能，并避免度量带来的负面效应。

参考答案：

核心要点：度量前端团队工程效能应结合 DORA、SPACE 框架和前端特有指标，形成“交付速度、交付质量、系统稳定性、开发者体验”四个维度的指标体系，并始终把度量用于改进而非考核。

详细解释：

1. 交付速度：需求前置时间、部署频率、本地构建时间、CI 时长、PR 合并时长。
2. 交付质量：缺陷逃逸率、测试覆盖率、自动化测试比例、Code Review 效率。
3. 系统稳定性：线上错误率、核心 Web Vitals、变更失败率、服务恢复时间、回滚频率。
4. 开发者体验：开发者 NPS、onboarding 天数、工具问题浪费的时间、文档搜索成功率。
5. 避免负面效应：不与个人绩效挂钩、不追求单一指标、团队参与制定、定期回顾指标有效性。

最佳实践：

• 从 3-5 个核心指标开始，逐步扩展。
• 指标要可自动采集，减少人工填报。
• 每个指标都要有对应改进 Owner 和行动项。

评分维度：

• 指标体系（40%）：能覆盖交付速度、质量、稳定性、开发者体验
• 框架应用（25%）：能结合 DORA、SPACE 框架
• 负面效应防范（35%）：能说明不挂钩绩效、防止造假、团队参与、定期回顾

常见错误：

• 用代码行数、提交次数等 vanity metrics 度量生产力
• 指标与绩效挂钩，导致开发者优化指标而非解决问题
• 指标太多，团队无所适从

延伸追问：

• 如果团队部署频率很高但缺陷也很多，这说明什么？
• 不同业务线的前端团队，指标口径如何统一？

相关题目：

• FB-21-CP-P-021 DORA 与 SPACE
• FB-21-SD-P-048 工程化度量平台

参考资源：

• DORA Core
• SPACE Framework

口头回答版：

度量前端团队效能要看四个方面：交付速度比如前置时间和部署频率，交付质量比如缺陷逃逸率和测试覆盖，系统稳定性比如错误率和恢复时间，开发者体验比如 NPS 和 onboarding 天数。可以结合 DORA 和 SPACE 框架。关键是度量用来改进流程，不要和个人绩效挂钩，指标要团队一起定，定期回顾有效性。

---

FB-21-SD-P-056：如何设计一个前端错误追踪与诊断平台？

题型：系统设计题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端工程化、可观测性、错误监控、系统设计 出现频率：中频 预计回答时长：10-15 分钟

题目描述： 请设计一个面向大型前端应用的错误追踪与诊断平台，覆盖错误采集、聚合、告警、诊断和复盘全链路。

参考答案：

核心要点：前端错误追踪平台应实现“从用户报错到开发者定位”的闭环，核心能力包括高性能采集、智能聚合、多维关联、回放诊断和事后复盘。

详细解释：

1. 错误采集：SDK 监听 onerror、unhandledrejection、fetch/xhr 拦截、资源加载；按类型/用户比例/环境配置采样；上下文包括 URL、浏览器、版本、用户 ID。
2. 聚合与降噪：基于堆栈指纹、错误消息、URL 聚合相似错误；区分首次和重复；标记状态避免告警风暴。
3. 告警与通知：按影响范围、频率、业务等级分级；支持邮件/IM/电话/工单；告警抑制避免轰炸。
4. 诊断能力：Source Map 还原、用户回放、关联 APM trace 和业务日志、影响面分析。
5. 复盘与改进：错误趋势看板、自动周报月报、与事故复盘流程对接。

最佳实践：

• SDK 轻量，不影响业务性能。
• 错误上报要脱敏和合规，不上传敏感信息。
• 建立错误 Owner 机制，每个高频错误有人跟进。

评分维度：

• 采集能力（25%）：能覆盖 JS 错误、资源、接口、上下文、采样
• 聚合告警（25%）：能说明指纹聚合、分级告警、告警抑制
• 诊断能力（30%）：能说明 Source Map、回放、日志关联、影响面分析
• 复盘改进（20%）：能说明趋势看板、错误 Owner、事故复盘对接

常见错误：

• 只采集不聚合，开发者被海量告警淹没
• Source Map 管理混乱，无法还原真实堆栈
• 忽略用户隐私，上传敏感信息

延伸追问：

• 如果错误发生在 Web Worker 或 Service Worker 中，如何采集？
• 如何设计 SDK 才能在不影响首屏性能的前提下采集错误？

相关题目：

• FB-21-EN-A-039 错误监控与告警体系
• FB-21-SD-R-061 前端研发效能数据中台

参考资源：

• Sentry Architecture
• Fundebug 前端监控

口头回答版：

前端错误追踪平台要能闭环。采集端 SDK 监听 onerror、unhandledrejection、接口和资源错误，带上下文和采样；服务端做指纹聚合和降噪，按影响分级告警；诊断时用 Source Map 还原堆栈、回放用户操作、关联日志；最后要有趋势看板和错误 Owner，推动复盘和修复。SDK 要轻量，注意隐私脱敏。

---

架构题（9 道）

FB-21-SD-R-057：如何设计一个支持多云部署的前端发布平台？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、CI/CD、云原生、平台工程、部署 出现频率：低频 预计回答时长：15-30 分钟

题目描述： 请设计一个支持多云环境（如阿里云、AWS、私有云）的前端发布平台，说明核心模块、部署流程和开发者使用体验。

参考答案：

核心要点：多云前端发布平台通过抽象构建产物、部署目标和发布策略，让开发者用统一接口完成发布，而底层根据环境选择不同的云服务商和部署方式。

详细解释：

1. 核心模块：构建中心、产物仓库、部署适配器、发布引擎、权限与审计、开发者门户。
2. 部署流程：提交代码 → CI 构建 → 产物上传 → 创建发布单 → 选择目标云和环境 → 灰度 → 监控验证 → 全量或回滚。
3. 多云适配策略：定义统一部署契约；每个云平台实现适配器插件；配置中心管理各云环境参数。
4. 开发者体验：一条命令完成发布、自动选择可用区、发布过程可观测、失败自动回滚、支持预览环境。

最佳实践：

• 产物标准化，避免与特定云平台绑定。
• 发布策略默认灰度，关键业务支持蓝绿部署。
• 建立跨云容灾和回滚机制。

评分维度：

• 架构设计（35%）：能说明构建中心、产物仓库、部署适配器、发布引擎、权限审计、门户
• 多云适配（25%）：能说明统一契约、适配器插件、配置中心
• 流程完整度（25%）：能描述从代码提交到灰度/全量/回滚的完整流程
• DX 设计（15%）：能说明统一命令、可观测性、自动回滚、预览环境

常见错误：

• 每个云平台独立一套发布流程
• 产物格式不统一，迁移成本高
• 忽略权限和审计，发布不可追溯

延伸追问：

• 不同云的 CDN 刷新策略不同，如何抽象？
• 如果某个云平台故障，如何快速切换到另一个云？

相关题目：

• FB-21-EN-B-038 CI/CD 基本概念
• FB-21-SD-R-024 平台工程体系设计

参考资源：

• AWS S3 Static Website Hosting
• Kubernetes Deployments

口头回答版：

多云前端发布平台要抽象构建、部署和发布三层。构建中心统一产出标准化产物，产物仓库管理版本，部署适配器把产物推到不同云的 OSS、S3、K8s 或 Serverless，发布引擎做灰度和回滚。开发者用一个命令就能发布到指定云和环境，过程可观测，失败自动回滚。关键是定义统一契约，避免被某一家云绑定。

---

FB-21-CP-R-058：如何从 0 到 1 搭建前端平台工程（Platform Engineering）团队？

题型：综合开放题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：平台工程、团队建设、前端工程化、开发者体验 出现频率：中频 预计回答时长：15-30 分钟

题目描述： 请说明在一个中大型前端组织中，如何从 0 到 1 搭建平台工程团队，包括目标定位、组织形式、能力建设和落地路径。

参考答案：

核心要点：前端平台工程团队应以“提升开发者体验和工程效能”为使命，通过内部产品化思维服务业务团队，而不是成为另一个审批或支撑部门。

详细解释：

1. 目标定位：抽象重复性工作、缩短需求交付周期、建立统一技术标准。
2. 组织形式：集中式平台团队、联邦式平台团队（平台+业务线代表）、产品化运营（设产品经理、技术布道师）。
3. 能力建设：第一阶段止痛（统一构建工具、脚手架、规范、CI 模板）；第二阶段提效（组件库、设计系统、Monorepo、文档门户）；第三阶段智能（效能度量、AI 辅助、自动诊断）。
4. 落地路径：识别高频痛点快速 early win、建立反馈机制、与业务团队共建、从项目制转向产品制。

最佳实践：

• 平台团队要有明确客户和成功指标。
• 提供自助服务，减少人工审批。
• 定期举办技术分享和培训，提升采用率。

评分维度：

• 定位清晰（25%）：能说明平台工程团队 mission 和服务对象
• 组织设计（25%）：能比较集中式、联邦式、产品化运营
• 能力建设（25%）：能按止痛、提效、智能分阶段建设
• 落地路径（25%）：能说明痛点识别、反馈机制、共建、产品化

常见错误：

• 平台团队变成纯支撑部门，没有产品思维
• 追求大而全，没有先解决最痛的点
• 不与业务团队共建，导致平台没人用

延伸追问：

• 平台团队的 KPI 应该如何设定？
• 当平台统一性与业务灵活性冲突时，如何取舍？

相关题目：

• FB-21-SD-R-024 平台工程体系设计
• FB-21-SS-R-030 证明 DX 业务价值

参考资源：

• Platform Engineering 白皮书
• Spotify 工程文化

口头回答版：

前端平台工程团队要以提升 DX 和效能为使命，把重复工作平台化。组织上可以是集中式或联邦式，最好有产品思维，把内部开发者当用户。建设分三阶段：先止痛统一工具链和规范，再提效做组件库、Monorepo、文档门户，最后智能化做度量、AI 辅助、自动诊断。落地要先抓最痛的点，和业务团队共建，持续收反馈。

---

FB-21-SD-R-059：如何设计一个前端资产（组件/页面）复用平台？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、组件库、设计系统、复用、平台工程 出现频率：中频 预计回答时长：15-30 分钟

题目描述： 请设计一个支持多技术栈、多业务线的前端资产复用平台，让组件和页面模板能被高效发现、使用和迭代。

参考答案：

核心要点：前端资产复用平台应以“可发现、可信任、可定制、可演进”为目标，通过统一资产标准、组件市场、文档示例和版本治理，降低重复开发成本。

详细解释：

1. 资产标准：定义元数据（名称、版本、技术栈、依赖、负责人）、统一打包规范、质量门禁（测试覆盖、视觉回归、a11y）。
2. 发现与使用：内部组件市场、IDE 集成、与文档门户打通。
3. 多技术栈支持：核心逻辑抽离为框架无关层、提供 React/Vue/小程序适配层、统一 Design Token。
4. 定制与反馈：支持 slot/props/主题配置、收集使用数据、建立贡献和退役机制。
5. 版本治理：SemVer 管理、重大变更提供 codemod、维护兼容矩阵。

最佳实践：

• 优先沉淀高频、稳定、跨业务复用的能力。
• 每个资产必须有 Owner 和明确维护策略。
• 通过使用率度量识别低价值资产并及时清理。

评分维度：

• 标准设计（30%）：能说明资产元数据、打包规范、质量门禁
• 发现使用（25%）：能说明组件市场、IDE 集成、文档门户
• 多栈支持（20%）：能说明框架无关层、适配层、Design Token
• 治理机制（25%）：能说明版本管理、贡献退役、使用率度量

常见错误：

• 把能复用的都塞入平台，导致资产臃肿
• 组件与业务逻辑耦合，无法跨业务使用
• 缺乏维护 Owner，资产长期不更新

延伸追问：

• 如何平衡组件通用性与业务定制化需求？
• 如果多个业务线都要改同一个组件，如何管理优先级？

相关题目：

• FB-21-SD-R-029 组件/文档/示例一体化工具链
• FB-21-SD-R-063 低代码平台 DX

参考资源：

• Storybook 组件市场
• Bit 组件平台

口头回答版：

前端资产复用平台要让组件和页面模板好发现、好信任、好定制。要定义统一的资产标准和元数据，建内部组件市场，和 IDE、文档门户打通。多技术栈可以用框架无关核心加 React/Vue 适配层。还要有版本治理、Owner 机制、使用率统计，定期清理没人用的资产。

---

FB-21-CP-R-060：大型企业前端工具链标准化应如何推进？

题型：综合开放题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、工具链、标准化、团队协作、平台工程 出现频率：中频 预计回答时长：15-30 分钟

题目描述： 在大型企业中，前端技术栈往往非常多样。请说明如何推进前端工具链标准化，同时保留必要的业务灵活性。

参考答案：

核心要点：工具链标准化不是消灭差异，而是建立“共同底座 + 可选扩展”的分层体系，通过治理委员会、模板市场和度量反馈逐步收敛，避免一刀切。

详细解释：

1. 标准化范围：必须统一（Node 版本、包管理器、代码规范、CI 模板、安全策略）；推荐统一（构建工具、测试框架、组件库、Monorepo）；允许差异（业务特定框架、特殊部署目标、实验性技术）。
2. 分层体系：基础层、平台层、业务层。
3. 推进策略：成立前端技术委员会、新建项目强制执行、存量项目设定迁移路线图、提供迁移工具和 codemod、设立例外审批机制。
4. 度量与治理：跟踪标准化覆盖率、迁移进度、工具满意度；定期复盘；纳入项目健康度评估。

最佳实践：

• 标准制定要让业务代表参与。
• 提供清晰的“为什么要统一”的理由和收益数据。
• 对拒绝统一的项目要有沟通和升级机制。

评分维度：

• 范围划分（30%）：能区分必须统一、推荐统一、允许差异
• 分层体系（25%）：能说明基础层、平台层、业务层
• 推进策略（25%）：能说明技术委员会、新建强制、存量迁移、例外审批
• 度量治理（20%）：能说明覆盖率、满意度、复盘机制

常见错误：

• 追求 100% 统一，扼杀业务创新和灵活性
• 标准制定不透明，业务团队不理解
• 没有迁移支持，存量项目无法落地

延伸追问：

• 如果某个核心业务拒绝迁移标准工具链，你怎么办？
• 如何度量标准化带来的实际收益？

相关题目：

• FB-21-CP-R-060 大型企业前端工具链标准化
• FB-21-SD-R-024 平台工程体系设计

参考资源：

• Thoughtworks Technology Radar
• Google Engineering Practices

口头回答版：

大企业工具链标准化不能一刀切。要分必须统一、推荐统一、允许差异三层。必须统一的是 Node 版本、包管理器、代码规范、CI 模板、安全策略；推荐统一构建工具和组件库；业务特定需求可以保留差异。推进时成立技术委员会，新建项目强制，存量项目给迁移路线和 codemod，还要有例外审批。定期度量覆盖率和满意度。

---

FB-21-SD-R-061：如何设计一个前端研发效能数据中台？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、效能度量、数据中台、可观测性、平台工程 出现频率：中频 预计回答时长：15-30 分钟

题目描述： 请设计一个前端研发效能数据中台，统一汇聚代码、CI/CD、发布、监控等多源数据，支撑团队度量、诊断和改进。

参考答案：

核心要点：前端研发效能数据中台通过统一数据模型、ETL 管道、指标计算和服务层，把分散的研发数据转化为可行动 insights，避免各团队重复建设和口径不一致。

详细解释：

1. 数据源接入：代码平台、CI/CD、构建工具、监控系统、协作工具。
2. 数据模型：统一实体（项目、团队、开发者、提交、发布、缺陷）、统一时间维度、统一指标定义。
3. 技术架构：采集层（Webhook/SDK/定时任务）、存储层（数据湖+数据仓库）、计算层（实时流+离线批处理）、服务层（指标 API/OLAP/告警/导出）、应用层（Dashboard/看板/报告）。
4. 数据治理：数据质量监控、权限控制、隐私合规。

最佳实践：

• 先统一指标定义，再建技术平台。
• 从 1-2 个核心场景验证价值，再扩展数据源。
• 明确数据中台是服务改进，不是监控个人。

评分维度：

• 数据源覆盖（25%）：能覆盖代码、CI/CD、构建、监控、协作工具
• 数据模型（20%）：能说明统一实体、时间维度、指标定义
• 技术架构（30%）：能说明采集、存储、计算、服务、应用层
• 数据治理（25%）：能说明质量监控、权限、隐私合规

常见错误：

• 先建平台再定义指标，导致数据无用
• 把数据中台做成个人绩效监控工具，引发抵触
• 忽视数据质量，指标口径混乱

延伸追问：

• 如何保证实时指标和离线指标的一致性？
• 多技术栈、多仓库场景下，如何统一项目标识？

相关题目：

• FB-21-SD-P-048 工程化度量平台
• FB-21-CP-P-055 度量团队整体工程效能

参考资源：

• dbt 数据转换
• 数据仓库工具箱

口头回答版：

前端研发效能数据中台要汇聚代码、CI/CD、构建、监控、协作工具的数据。先定义统一的数据模型和指标口径，技术上分采集层、数据湖/仓库、计算层、服务层和应用层。要注意数据治理，包括质量监控、权限控制和隐私合规。关键是先统一指标定义，再建平台，而且明确是服务改进不是监控个人。

---

FB-21-SS-R-062：如何推动组织层面的 DX 文化变革？

题型：软技能题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：开发者体验、软技能、组织变革、团队协作、平台工程 出现频率：中频 预计回答时长：10-15 分钟

题目描述： DX 不仅是工具和流程，更是组织文化。请说明如何在大型组织中推动以开发者体验为核心的文化变革。

参考答案：

核心要点：推动 DX 文化变革需要从领导层支持、度量透明、故事传播、激励机制和持续教育五个方面入手，把“关注开发者效率”变成组织共同信念。

详细解释：

1. 获得领导层支持：用业务语言证明 DX 价值，争取 dedicated 预算和编制，让高管参与关键决策。
2. 建立度量与透明：公开 DX 指标和趋势，设立 DX 看板，定期发布健康报告。
3. 传播成功故事：收集具体案例，内部技术大会/博客/视频分享，邀请业务负责人站台。
4. 激励机制：把 DX 改进纳入绩效和晋升，设立 DX 奖项，给参与者成长机会。
5. 持续教育：定期培训、建立 DX 布道师网络、把 DX 纳入新员工 onboarding。

最佳实践：

• 从小胜利开始，逐步扩大影响。
• 避免把 DX 变成口号，要有具体行动和结果。
• 让开发者参与定义什么是“好的 DX”。

评分维度：

• 领导层支持（25%）：能说明如何用业务语言争取资源
• 度量透明（20%）：能说明 DX 看板、健康报告
• 故事传播（20%）：能说明案例收集、内部宣传
• 激励教育（20%）：能说明绩效认可、培训、布道师
• 落地节奏（15%）：能说明小胜利、行动导向、开发者参与

常见错误：

• 只有工具改进，没有文化层面的宣传和激励
• 把 DX 指标与个人绩效挂钩，引发抵触
• 急于求成，没有耐心培育文化

延伸追问：

• 如果领导层不认可 DX，你如何自下而上推动？
• DX 文化与业务交付压力冲突时，如何取舍？

相关题目：

• FB-21-SS-R-030 证明 DX 业务价值
• FB-21-SS-P-020 推动统一 DX 平台

参考资源：

• The Business Value of DX
• DevEx 调研报告

口头回答版：

推动 DX 文化要几方面一起用力：先向领导层证明业务价值争取资源；建立 DX 看板公开度量；收集成功案例内部传播；把 DX 改进纳入绩效和晋升；定期培训和布道。要从小胜利开始，让开发者参与定义好的 DX，不要变成口号。

---

FB-21-SD-R-063：如何设计一个低代码搭建平台的开发者体验？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：低代码、前端工程化、开发者体验、平台工程、设计系统 出现频率：低频 预计回答时长：15-30 分钟

题目描述： 请设计一个低代码/无代码搭建平台的开发者体验，让业务人员能高效搭建页面，同时让专业开发者能扩展能力和排查问题。

参考答案：

核心要点：低代码平台的 DX 设计要服务两类用户：业务人员需要直观、快速、可验证；专业开发者需要可扩展、可调试、可集成。平台应在可视化与代码之间建立双向通道。

详细解释：

1. 业务人员体验：模板市场、拖拽编辑、数据绑定、一键预览与发布、沙箱环境。
2. 专业开发者体验：组件扩展 SDK、代码导出、调试能力（控制台/网络/性能/错误）、Git 式版本管理和 diff。
3. 平台核心能力：Schema 驱动页面配置、Design Token 集成、权限与协作、性能保障（产物经过构建优化）。
4. 边界与权衡：适合营销页、后台表单、数据展示；不适合复杂交互、高性能、强定制需求；提供退出机制转交专业开发。

最佳实践：

• 组件和模板要经过设计系统审核。
• 提供专业开发者的本地调试环境。
• 建立用户反馈渠道，持续优化操作路径。

评分维度：

• 业务人员 DX（30%）：能说明模板、拖拽、数据绑定、预览发布
• 专业开发者 DX（30%）：能说明组件扩展、代码导出、调试、版本管理
• 平台能力（25%）：能说明 Schema 驱动、Design Token、权限协作、性能
• 边界意识（15%）：能说明适合场景和退出机制

常见错误：

• 只关注业务人员，忽视专业开发者扩展和调试需求
• 低代码产物无法导出或维护，形成锁定
• 试图用低代码解决所有问题，导致平台过度复杂

延伸追问：

• 如何保证低代码产物的性能和可访问性？
• 如果业务人员搭建的页面出了问题，如何快速定位和回滚？

相关题目：

• FB-21-SD-R-029 组件/文档/示例一体化工具链
• FB-21-SD-R-059 前端资产复用平台

参考资源：

• Low-Code/No-Code 平台设计
• Retool 设计原则

口头回答版：

低代码平台要兼顾两类用户。业务人员要模板、拖拽、数据绑定、一键预览发布；专业开发者要能扩展组件、导出代码、调试和版本管理。平台用 Schema 驱动页面配置，集成 Design Token 和权限协作。要明确适合场景，复杂需求要有退出机制交给专业开发。

---

FB-21-CP-R-064：前端工程化体系应如何持续演进？

题型：综合开放题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、平台工程、技术演进、团队协作 出现频率：中频 预计回答时长：10-15 分钟

题目描述： 前端技术和业务需求不断变化，请说明如何让前端工程化体系保持活力，避免僵化或过度追新。

参考答案：

核心要点：前端工程化体系的持续演进需要建立“输入-决策-实验-推广-退役”的闭环，以真实痛点和度量为驱动，而不是追逐技术热点。

详细解释：

1. 输入机制：定期收集开发者反馈、跟踪技术趋势、监控内部指标。
2. 决策机制：成立技术委员会、使用 RFC 流程、决策标准包括问题紧迫度、收益可量化、团队适配性、长期成本。
3. 实验机制：设立创新时间或实验项目，明确目标、评估周期和退出条件。
4. 推广与退役：新技术通过模板、文档、培训推广；老技术设定退役路线图；及时清理不再维护的工具。
5. 平衡原则：不因“新”而引入，也不因“老”而拒绝；核心稳定、边缘创新；演进节奏与业务周期对齐。

最佳实践：

• 每年做一次工程化体系健康度评估。
• 把演进计划纳入技术 Roadmap，与业务规划同步。
• 保留一定比例的技术债预算用于基础设施升级。

评分维度：

• 闭环设计（35%）：能说明输入、决策、实验、推广、退役机制
• 数据驱动（25%）：能说明反馈收集、指标监控、实验评估
• 平衡意识（25%）：能说明不追新、核心稳定、边缘创新
• 落地节奏（15%）：能说明 Roadmap 对齐、技术债预算

常见错误：

• 技术栈长期不更新，逐渐落后
• 频繁追逐新技术，团队疲于迁移
• 没有决策机制，靠个人偏好选型

延伸追问：

• 如何平衡基础设施升级和业务功能开发？
• 如果一项核心技术已经落后但迁移成本极高，你会怎么处理？

相关题目：

• FB-21-CP-P-050 评估新技术引入
• FB-21-SS-P-053 技术债治理

参考资源：

• Technology Radar
• Google Engineering Practices

口头回答版：

前端工程化体系要持续演进，建立输入、决策、实验、推广、退役的闭环。输入来自开发者反馈、技术趋势和内部指标；决策用技术委员会和 RFC；实验要明确目标和退出条件；老技术要设退役路线。核心要稳定，边缘可以创新，节奏要和业务周期对齐，还要留技术债预算。

---

FB-21-SD-R-065：如何设计一个全球化的前端研发协同平台？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：前端工程化、全球化、团队协作、平台工程、开发者体验 出现频率：低频 预计回答时长：15-30 分钟

题目描述： 请设计一个支持多地、多语言、多时区团队协同的前端研发平台，解决代码协作、沟通、发布和文化差异带来的挑战。

参考答案：

核心要点：全球化前端研发协同平台应通过异步协作、统一工具链、区域化部署和文化包容性设计，让分布在全球的团队能够高效、稳定地协同交付。

详细解释：

1. 代码协作：Monorepo + 强大的 CI/缓存；代码审查工具支持异步 Review；提交信息用英文统一。
2. 沟通与文档：决策和讨论以书面形式沉淀；重要会议录屏并生成纪要；文档站点支持多语言。
3. 区域化部署：各地有就近的代码仓库镜像、CI runner、产物仓库和部署节点；支持按区域灰度发布。
4. 工具链统一：全球团队使用同一套脚手架、组件库、Design Token、发布平台，减少分支和差异。
5. 文化与流程：重叠工作时间用于同步沟通；设立区域技术负责人；尊重节假日和工作习惯差异。

最佳实践：

• 所有重要决策必须留下可追溯的文档或 RFC。
• CI 和构建缓存要区域化，避免跨国网络瓶颈。
• 定期举办全球技术同步会，分享各区域最佳实践。

评分维度：

• 代码协作（25%）：能说明 Monorepo、异步 Review、统一提交信息
• 沟通文档（20%）：能说明书面沉淀、录屏纪要、多语言文档
• 区域化部署（25%）：能说明镜像、runner、产物仓库、区域灰度
• 工具统一（15%）：能说明统一脚手架、组件库、发布平台
• 文化流程（15%）：能说明重叠时间、区域负责人、尊重差异

常见错误：

• 要求全球团队同步工作，忽视时区差异
• 各地使用不同工具链，导致代码和流程分裂
• 文档只有中文或英文，影响非母语团队

延伸追问：

• 如果某个区域网络不稳定，如何保证 CI 和发布不受影响？
• 如何处理不同区域对数据合规和隐私的不同要求？

相关题目：

• FB-21-SD-R-057 多云部署平台
• FB-21-SD-R-061 前端研发效能数据中台

参考资源：

• GitLab Remote Playbook
• Atlassian - Distributed Teams

口头回答版：

全球化前端协同平台要解决代码协作、沟通、部署和文化差异。代码用 Monorepo 和异步 Review；沟通要书面沉淀、会议录屏、文档多语言；部署要区域化镜像、runner、产物仓库和灰度；工具链全球统一。还要尊重时区和文化差异，设区域技术负责人，重要决策都要留文档。

---

基础题（6 道）

FB-21-CO-B-066：什么是构建产物可复现性？为什么对 DX 重要？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、构建工具、可复现性、CI/CD、开发者体验 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请解释构建产物可复现性（Reproducible Builds）的含义，并说明它如何影响开发者体验和线上问题排查。

参考答案：

核心要点：构建产物可复现性指在相同源码、相同依赖和相同构建环境下，多次构建应产出完全一致的产物；它是团队协作、问题回溯和安全审计的基础。

详细解释：

1. 什么是可复现性

   • 相同的 Git commit、lock 文件、Node 版本、构建脚本，应产出字节级一致或语义一致的产物。
   • 影响因素包括：依赖版本、构建工具版本、环境变量、时区、文件路径、并行执行顺序。

2. 对 DX 的意义

   • 问题定位：线上异常包可以本地精确复现，缩短排查时间。
   • 安全审计：防止构建环境被注入恶意代码后无法比对。
   • 缓存命中：可复现的输入输出更有利于 Turborepo / Nx 等缓存系统。
   • 协作信任：不同成员构建结果一致，减少“我本地没问题”的争议。

3. 实现要点

   • 提交 lock 文件，统一包管理器和 Node 版本。
   • 在 CI 中使用容器化或固定 runner 镜像。
   • 避免在构建中引入非确定性数据（如构建时间戳、随机数、绝对路径）。

最佳实践：

• 将 packageManager、engines、.nvmrc 纳入版本控制。
• CI 与本地使用相同的 Docker 镜像或 runner 版本。
• 对产物做哈希校验，作为发布门禁。

评分维度：

• 概念准确性（40%）：能说明可复现性的核心是同源同环境同产物
• 影响因素（30%）：能列举依赖、工具版本、环境变量、时区等影响因素
• DX 价值（30%）：能联系问题复现、缓存、安全审计和协作信任

常见错误：

• 认为可复现性只与安全相关，忽略日常排查和缓存
• 不提交 lock 文件却要求构建一致
• 在产物中嵌入时间戳或机器路径导致不可复现

延伸追问：

• 如果两个 CI runner 构建产物哈希不同，你会如何排查？
• npm 的 deterministic install 和 pnpm 的内容可寻址存储各有什么优劣？

相关题目：

• FB-21-EN-B-032 package.json scripts 设计原则
• FB-21-EN-A-039 错误监控与告警体系

参考资源：

• Reproducible Builds
• npm ci vs npm install

口头回答版：

构建产物可复现性就是同样的代码、同样的依赖、同样的环境，每次构建出来的东西应该一样。这对 DX 很重要，因为线上出了问题我们可以本地精确复现，缓存也更稳定，团队之间不会因为构建结果不一样而扯皮。要做到这点，就要提交 lock 文件、统一 Node 和包管理器版本、CI 用固定镜像，避免在产物里放时间戳或随机数。

---

FB-21-EN-B-067：前端项目中的 .gitignore 应该忽略哪些文件？忽略不当会有什么风险？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、Git、开发者体验、环境配置、依赖管理 出现频率：高频 预计回答时长：2-3 分钟

题目描述： 请说明前端项目 .gitignore 中通常应忽略哪些文件，并解释如果忽略不当会带来什么问题。

参考答案：

核心要点：.gitignore 应忽略自动生成的、环境相关的、体积大的或个人私密的文件；忽略不当会导致仓库膨胀、敏感信息泄露或协作冲突。

详细解释：

1. 应忽略的内容

   • 依赖目录：node_modules/、bower_components/。
   • 构建产物：dist/、build/、.next/、.output/。
   • 环境变量：.env、.env.local、.env.*.local。
   • 日志与缓存：logs/、*.log、.cache/、.eslintcache。
   • 编辑器/系统文件：.DS_Store、.idea/、.vscode/（团队共享配置除外）。
   • 测试与覆盖率产物：coverage/。

2. 不应忽略的关键文件

   • lock 文件：package-lock.json、pnpm-lock.yaml、yarn.lock。
   • 示例环境文件：.env.example。
   • 团队共享的编辑器配置：.vscode/settings.json（如已约定统一）。

3. 忽略不当的风险

   • 提交 node_modules：仓库体积剧增，克隆极慢。
   • 提交 .env：密钥泄露，造成安全事故。
   • 提交构建产物：引发冲突，且产物与源码不一致。
   • 忽略 lock 文件：依赖版本漂移，CI 与本地行为不一致。

最佳实践：

• 使用 GitHub 的 Node.gitignore 模板作为起点。
• 对必须共享的环境变量提供 .env.example 并说明获取方式。
• 定期检查仓库体积，清理误提交的大文件。

评分维度：

• 分类清晰（40%）：能按依赖、产物、环境、日志、缓存等分类说明
• 风险识别（35%）：能说明忽略或误提交带来的安全、体积、一致性问题
• 最佳实践（25%）：能提到 lock 文件保留、.env.example、模板起点

常见错误：

• 把 lock 文件加入 .gitignore
• 把团队共享的 .vscode/settings.json 也忽略
• 只忽略 node_modules，忽略日志、缓存等其他自动生成文件

延伸追问：

• 如果已经误提交了大文件到 Git 历史，如何清理？
• .gitignore 和 .git/info/exclude 有什么区别？

相关题目：

• FB-21-CO-B-007 本地开发环境一致性
• FB-21-EN-B-038 CI/CD 基本概念

参考资源：

• Git - gitignore 文档
• GitHub Node.gitignore 模板

口头回答版：

.gitignore 主要忽略自动生成、环境相关、体积大或私密的东西，比如 node_modules、构建产物 dist、环境变量 .env、日志、缓存、.DS_Store 这些。但要注意 lock 文件不能忽略，团队共享的编辑器配置也可以保留。如果忽略不当，比如把 node_modules 提交上去仓库会很大，把 .env 提交会泄露密钥，忽略 lock 文件会导致依赖版本不一致。

---

FB-21-CO-B-068：什么是可观测性（Observability）？它包含哪些核心维度？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：可观测性、前端监控、日志、指标、链路追踪 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 请解释可观测性的概念，并说明前端工程中的可观测性通常包含哪几个核心维度。

参考答案：

核心要点：可观测性指通过系统外部输出（日志、指标、链路）理解系统内部状态的能力；前端可观测性通常包括日志、指标、链路追踪和用户会话回放。

详细解释：

1. 可观测性的定义

   • 源自控制论，强调在不查看源码的情况下，通过外部数据推断系统行为。
   • 与单纯“监控”的区别：监控是已知问题的告警，可观测性更强调未知问题的探索。

2. 前端可观测性的四大维度

   • 日志（Logs）：结构化记录错误、事件和行为，如 console、Sentry 报错。
   • 指标（Metrics）：量化数据，如页面加载时间、JS 错误率、API 成功率、构建时长。
   • 链路追踪（Traces）：跨服务、跨端的请求链路，如 OpenTelemetry、SkyWalking。
   • 用户会话回放（Replay）：记录用户操作和页面状态，辅助复现问题。

3. 与 DX 的关系

   • 可观测性数据帮助开发者快速定位问题，缩短 MTTR（平均修复时间）。
   • 工程效能指标（构建时长、测试通过率）也是可观测性的一部分。

最佳实践：

• 统一数据模型和字段规范，便于跨系统关联。
• 采样与脱敏结合，避免全量采集带来的成本和隐私风险。
• 将可观测性嵌入脚手架，新项目默认接入。

评分维度：

• 概念理解（40%）：能区分可观测性与监控，说明外部输出的意义
• 维度覆盖（35%）：能列举日志、指标、链路、会话回放等核心维度
• DX 联系（25%）：能说明可观测性如何缩短排查时间和提升效能

常见错误：

• 把可观测性等同于错误监控
• 忽略前端特有的维度，如用户回放、资源加载指标
• 只采集不治理，导致数据噪音大、查询困难

延伸追问：

• 前端链路追踪和后端微服务链路追踪如何关联？
• 可观测性数据采集如何避免影响页面性能？

相关题目：

• FB-21-EN-A-039 错误监控与告警体系
• FB-21-SD-P-056 前端错误追踪与诊断平台

参考资源：

• OpenTelemetry 文档
• Google SRE - Monitoring Distributed Systems

口头回答版：

可观测性就是通过系统外部输出，比如日志、指标、链路，去理解系统内部发生了什么。前端可观测性通常包括日志、指标、链路追踪和用户会话回放。它和监控不一样，监控是已知问题的告警，可观测性更强调排查未知问题。好的可观测性能让开发者更快定位 Bug，也能度量工程效能，比如构建时长、测试通过率。

---

FB-21-EN-B-069：如何为前端项目选择合适的包管理器？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：npm、yarn、pnpm、包管理器、前端工程化 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 请对比 npm、yarn、pnpm 等主流包管理器，并说明选择时应考虑哪些因素。

参考答案：

核心要点：选择包管理器应综合考虑安装速度、磁盘占用、依赖严格性、Monorepo 支持、团队熟悉度和生态兼容性；pnpm 在大多数现代前端项目中具有综合优势。

详细解释：

1. 主流包管理器对比

维度	npm	yarn	pnpm
安装速度	中等	快（PnP/缓存）	快（硬链接）
磁盘占用	大	大	小（内容可寻址）
幽灵依赖	常见	常见	严格（默认不可访问未声明依赖）
Monorepo	workspaces	workspaces	workspaces + 更优
lock 文件	package-lock.json	yarn.lock	pnpm-lock.yaml

2. 选择因素

   • 项目规模：小型项目三者差异不大；Monorepo 优先考虑 pnpm 或 yarn Berry。
   • 团队熟悉度：生态和团队经验有时比技术优劣更重要。
   • CI 一致性：lock 文件格式和缓存策略是否与现有 CI 兼容。
   • 依赖安全：pnpm 的严格依赖树可减少幽灵依赖带来的风险。

3. 迁移成本

   • 切换包管理器需要清理 node_modules、重新生成 lock 文件、验证 CI 脚本。
   • 大型项目迁移应分阶段，先在小项目试点。

最佳实践：

• 用 packageManager 字段锁定包管理器版本（corepack）。
• 在 CI 中缓存包管理器的全局存储目录。
• 统一团队包管理器，避免混用导致 lock 冲突。

评分维度：

• 对比能力（40%）：能从速度、体积、严格性、Monorepo 等维度对比
• 选型依据（35%）：能结合项目规模、团队、CI、安全说明选择理由
• 落地意识（25%）：能提到 packageManager、lock 文件、CI 缓存

常见错误：

• 盲目追求最新工具，忽略团队学习成本
• 不同成员使用不同包管理器，导致 lock 文件反复冲突
• 忽略幽灵依赖问题，认为能跑就行

延伸追问：

• pnpm 的严格依赖结构可能带来哪些兼容性问题？
• yarn PnP 和 node_modules 方案各有什么适用场景？

相关题目：

• FB-21-CO-B-003 Monorepo 与 Multirepo 差异
• FB-21-EN-A-010 pnpm workspace + Turborepo

参考资源：

• pnpm 官方文档
• yarn 官方文档

口头回答版：

选包管理器要看安装速度、磁盘占用、依赖严格性、Monorepo 支持和团队熟悉度。pnpm 用内容可寻址存储，磁盘占用小，默认严格依赖，Monorepo 支持也好。npm 和 yarn 也很成熟，但容易产生幽灵依赖。选型还要考虑 CI 兼容和迁移成本。建议用 packageManager 字段锁定版本，团队统一用一个。

---

FB-21-CO-B-070：什么是技术债？它与开发者体验有什么关系？

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：技术债、代码质量、工程效能、团队协同、重构 出现频率：高频 预计回答时长：3-5 分钟

题目描述： 请解释技术债的概念，并说明技术债如何影响开发者体验和工程效能。

参考答案：

核心要点：技术债是为了短期交付而做出的技术妥协，若不及时偿还，会累积成开发阻力，直接影响开发者体验、交付速度和质量。

详细解释：

1. 技术债的类型

   • 代码债：重复代码、命名混乱、缺乏测试。
   • 架构债：模块边界模糊、耦合严重。
   • 工具债：过时的构建工具、缺失的自动化流程。
   • 文档债：文档缺失或过期。
   • 人员债：关键知识只掌握在少数人手中。

2. 对 DX 的影响

   • 开发效率下降：修改一处代码需要理解大量上下文，Bug 频发。
   • 心理负担增加：开发者害怕触碰老代码，士气下降。
   • onboarding 成本上升：新人难以理解系统，上手慢。
   • 反馈循环变长：构建慢、测试慢、发布慢。

3. 管理思路

   • 识别并登记技术债，评估影响和偿还成本。
   • 在迭代中预留固定比例的时间用于还债。
   • 通过重构、补测试、升级工具逐步改善。

最佳实践：

• 建立技术债登记册（Tech Debt Register），定期 review。
• 新功能开发时遵循“童子军规则”：离开代码时比来时更干净。
• 用指标度量技术债的影响，如缺陷率、修改成本、构建时间。

评分维度：

• 概念理解（40%）：能解释技术债是短期妥协和长期成本
• 类型识别（30%）：能列举代码债、架构债、工具债、文档债等
• DX 联系（30%）：能说明对效率、心理负担、onboarding、反馈循环的影响

常见错误：

• 把技术债简单等同于 Bug
• 认为技术债永远不应该存在，忽略业务节奏
• 只登记不还债，导致登记册流于形式

延伸追问：

• 如何向产品经理解释技术债需要占用迭代时间？
• 如何判断一项技术债应该立即偿还还是可以延后？

相关题目：

• FB-21-SS-P-053 技术债治理流程
• FB-21-SC-P-047 跨团队组件共享

参考资源：

• Martin Fowler - Technical Debt
• Google - Managing Technical Debt

口头回答版：

技术债是为了赶进度而做的技术妥协，比如代码写得潦草、没测试、工具老旧。它会让后续开发越来越难，改一处动全身，Bug 变多，新人上手慢，大家也不愿意碰老代码。管理技术债要登记、评估、留时间还，比如每次迭代拿一定比例做重构和补测试，不能让债一直滚。

---

FB-21-EN-B-071：前端项目中的环境变量有哪些安全注意事项？

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、环境变量、安全、构建工具、配置管理 出现频率：中频 预计回答时长：2-3 分钟

题目描述： 请说明前端项目使用环境变量时应注意哪些安全问题，并给出最佳实践。

参考答案：

核心要点：前端环境变量最终可能被打包到客户端，因此不能存放密钥；应区分公共变量与私密变量，严格控制其作用域和访问方式。

详细解释：

1. 前端环境变量的特殊性

   • 构建时会通过 import.meta.env 或 process.env 替换并打包到产物中。
   • 任何以客户端形式下发的变量都可被用户查看，不能视为安全。

2. 安全注意事项

   • 不要把密钥放入前端环境变量：API 密钥、数据库密码、私钥等应放在服务端。
   • 区分公共与私密变量：Vite 的 VITE_ 前缀变量会暴露到客户端；服务端专用变量不加此前缀。
   • 避免提交 .env 文件：应将 .env 加入 .gitignore，提供 .env.example。
   • 最小权限原则：只暴露前端真正需要的变量，如 API 基础路径、功能开关。
   • 验证和兜底：读取环境变量时提供默认值和类型校验，防止构建失败。

3. 密钥的安全使用方式

   • 通过服务端 API 代理调用需要鉴权的第三方服务。
   • 使用服务器端渲染时在服务端获取密钥，不向客户端泄露。

最佳实践：

• 提交 .env.example 说明所需变量，不提交真实 .env。
• 在 CI 中通过 secrets 注入敏感配置。
• 定期扫描仓库历史，防止密钥泄露。

评分维度：

• 风险识别（40%）：能说明前端 env 会打包到客户端，不能存密钥
• 分类意识（30%）：能区分公共变量与私密变量、客户端变量与服务端变量
• 落地实践（30%）：能提到 .gitignore、.env.example、CI secrets、最小权限

常见错误：

• 把 API 密钥直接写进前端代码或环境变量
• 认为只要文件名是 .env 就不会泄露
• 所有配置都用环境变量，导致构建产物不可预测

延伸追问：

• 如果密钥已经误提交到 Git，应该如何应急处理？
• SSR 项目中如何安全地在服务端使用环境变量？

相关题目：

• FB-21-EN-B-067 .gitignore 配置
• FB-21-EN-A-046 环境变量管理最佳实践

参考资源：

• Vite - Env Variables
• OWASP - Secrets Management

口头回答版：

前端环境变量要特别注意安全，因为它们最后会打包到客户端，用户是能看到的。不能把 API 密钥、数据库密码这类敏感信息放到前端 env 里。要区分客户端变量和服务端变量，Vite 里只有 VITE_ 前缀的会暴露到客户端。不要提交 .env 文件，要提供 .env.example，CI 里用 secrets 注入敏感配置。前端只暴露真正需要的东西，比如接口地址和功能开关。

---

进阶题（7 道）

FB-21-SC-A-072：新成员入职第一周配不好环境，如何设计一键 onboarding 方案？

题型：场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：开发者体验、onboarding、Dev Container、脚手架、自动化 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 团队新成员经常在第一周卡在环境配置、权限申请和工具安装上。请设计一套一键 onboarding 方案，让新人在一天内进入开发状态。

参考答案：

核心要点：一键 onboarding 应将环境、依赖、权限、配置和验证流程自动化，并通过文档和引导脚本降低新人认知负担。

详细解释：

1. 问题拆解

   • 环境差异：Node、包管理器、编辑器版本不一致。
   • 权限壁垒：代码仓库、CI、内部平台账号未开通。
   • 配置复杂：需要手动设置环境变量、VPN、SSH key。
   • 验证困难：不知道本地是否真正跑通了。

2. 方案设计

   • Dev Container / Docker：把开发环境打包成镜像，新人一键启动。
   • Onboarding CLI：提供内部 CLI 工具，自动完成：
     • 检查 Node / Git / 包管理器版本。
     • 克隆仓库、安装依赖、复制 .env.example。
     • 生成 SSH key、配置 Git 用户信息。
     • 运行健康检查脚本，验证构建、测试、预览是否正常。
   • 权限自动化：与 IAM / SSO 集成，自动加入对应仓库和群组。
   • 交互式文档：Step-by-step 向导，每步有验证命令和常见错误处理。

3. 成功指标

   • 从拿到账号到首次成功提交 PR 的时间。
   • 第一周因环境问题发起 support 工单的次数。
   • 新人满意度评分。

最佳实践：

• 将 onboarding 脚本也纳入 CI，确保脚本本身不过期。
• 建立“环境医生”机制，自动诊断常见失败原因。
• 定期邀请新人反馈，持续优化 onboarding 流程。

评分维度：

• 问题拆解（30%）：能识别环境、权限、配置、验证等痛点
• 方案完整性（40%）：能覆盖容器化、CLI 自动化、权限、文档
• 可度量性（30%）：能定义 onboarding 时长、工单数、满意度等指标

常见错误：

• 只提供文字文档，没有自动化脚本
• 忽略权限和账号开通的瓶颈
• onboarding 脚本不维护，新人照着做却跑不通

延伸追问：

• 如果团队有人坚持用本地环境不用 Dev Container，如何兼容？
• 如何确保 onboarding 脚本在 Mac、Windows、Linux 上都可用？

相关题目：

• FB-21-EN-P-019 Dev Container 配置与实践
• FB-21-SC-P-023 新成员 onboarding 流程

参考资源：

• GitHub Codespaces 文档
• VS Code Dev Containers

口头回答版：

新成员配环境慢，主要是因为环境、权限、配置、验证这几块都靠手动。可以设计一套一键 onboarding：用 Dev Container 或 Docker 把环境打包；做一个内部 CLI，自动检查版本、克隆仓库、装依赖、配 env、跑健康检查；权限尽量和 SSO 集成自动开通；文档做成交互式向导。成功指标可以看成从拿到账号到第一次提交 PR 要多久，第一周环境问题工单有多少。

---

FB-21-EN-A-073：如何为前端项目设计分层测试策略？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端测试、单元测试、集成测试、E2E、测试策略 出现频率：高频 预计回答时长：5-8 分钟

题目描述： 请说明前端项目中分层测试策略的原则，并给出不同测试层的职责、工具选择和运行时机建议。

参考答案：

核心要点：分层测试策略通过单元、集成、E2E 等不同粒度测试的组合，在成本与信心之间取得平衡；应遵循“测试金字塔”，让快速、廉价的测试占多数。

详细解释：

1. 测试金字塔

   • 单元测试（底层，最多）：测试函数、组件、工具方法，速度快、成本低。
   • 集成测试（中层）：测试模块间协作、API 接口、状态流转。
   • E2E 测试（顶层，最少）：模拟真实用户操作，覆盖关键路径，成本高、速度慢。

2. 工具选择

   • 单元：Vitest / Jest + Testing Library / Vue Test Utils。
   • 集成：MSW 模拟 API + Testing Library 组件渲染。
   • E2E：Playwright / Cypress。
   • 视觉回归：Chromatic / Percy。

3. 运行时机

   • 单元和集成：pre-commit 或 PR 阶段快速运行。
   • E2E：合并到主干前或夜间构建运行。
   • 全量测试：发布前必须通过。

4. 设计原则

   • 优先覆盖高价值路径和高风险区域。
   • 测试应稳定、可维护，避免过度依赖实现细节。
   • 用 Mock 控制外部依赖，减少 flaky 测试。

最佳实践：

• 设定覆盖率门禁，但不过度追求 100% 覆盖率。
• 对 flaky 测试零容忍，发现后优先修复或移除。
• 让测试代码与业务代码同仓库，同步维护。

评分维度：

• 分层理解（40%）：能说明单元、集成、E2E 的职责和比例
• 工具选型（30%）：能结合 Vitest/Testing Library/Playwright 等说明
• 落地时机（30%）：能说明不同层在 pre-commit/PR/合并前/发布前的运行策略

常见错误：

• 只写 E2E，忽略单元和集成，导致测试极慢且不稳定
• 测试过度依赖 DOM 结构或内部实现，导致重构时大量失败
• 把测试当成一次性任务，不随着代码演进维护

延伸追问：

• 如何处理前端测试中的 flaky 测试？
• 单元测试覆盖率 100% 是否意味着代码质量高？

相关题目：

• FB-21-CP-R-028 自动化测试 ROI
• FB-21-PE-P-051 构建缓存失效原因

参考资源：

• Testing Pyramid
• Playwright 官方文档

口头回答版：

前端测试要分层，像金字塔一样：底层是单元测试，最多，跑得快；中间是集成测试，测模块协作；顶层是 E2E，测真实用户路径，但数量要少。单元用 Vitest/Jest，集成用 MSW 加 Testing Library，E2E 用 Playwright 或 Cypress。单元和集成在 PR 时跑，E2E 合并前或夜间跑。测试要稳定，别过度依赖实现细节，flaky 测试要及时修。

---

FB-21-PE-A-074：前端项目的 HMR 失效或变慢，如何排查和优化？

题型：性能优化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：HMR、Vite、Webpack、性能优化、开发者体验 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 本地开发时热更新（HMR）变慢或完全失效，请给出系统性的排查思路和优化手段。

参考答案：

核心要点：HMR 问题通常源于文件监听上限、构建配置、依赖体积、自定义 loader 或网络代理；排查应从现象出发，逐步定位到文件监听、模块解析和更新推送链路。

详细解释：

1. 常见现象与原因

   • 完全失效：文件修改后页面不刷新。
     • 可能原因：监听的文件数超过 OS 上限、watch 配置错误、WSL 文件系统问题。
   • 变慢：保存后几秒才更新。
     • 可能原因：大型依赖未排除、自定义 plugin/loader 慢、Source Map 生成慢、代理网络延迟。

2. 排查步骤

   • 检查系统文件监听上限：fs.inotify.max_user_watches（Linux）。
   • 用 Vite 的 DEBUG=vite:hmr 或 Webpack 的 stats 查看 HMR 日志。
   • 检查是否有自定义 plugin 处理所有文件，尤其是 Markdown/JSON/YAML。
   • 排查是否引入了整个大库（如 lodash 全量引入）。
   • 确认代理、VPN、Docker 卷挂载是否造成网络或 I/O 瓶颈。

3. 优化手段

   • 排除不需要监听的目录：node_modules、日志、大资源目录。
   • 按需加载第三方库，使用 ESM 版本。
   • 拆分大型路由或组件，减少单次更新范围。
   • 升级构建工具到支持 ESM-HMR 的版本（如 Vite）。
   • 对 WSL / Docker 使用 native filesystem 或增加内存。

最佳实践：

• 定期测量本地 dev server 的冷启动和热更新耗时。
• 对大型项目使用 Module Federation 或微前端拆分开发范围。
• 保持构建工具和依赖的合理版本，及时清理废弃配置。

评分维度：

• 排查思路（40%）：能按现象分类，逐步定位文件监听、模块解析、推送链路
• 优化手段（35%）：能提到排除目录、按需加载、ESM、拆分、WSL 优化
• 工具使用（25%）：能使用 DEBUG 日志、stats、系统参数等定位问题

常见错误：

• 一遇到 HMR 慢就升级硬件，不分析根本原因
• 在开发环境引入未压缩的完整库
• 忽略 WSL / Docker 文件系统的特殊性

延伸追问：

• Webpack 的 HMR 和 Vite 的 HMR 在实现上有什么本质区别？
• 如何在微前端架构中保持子应用 HMR 的独立性？

相关题目：

• FB-21-PE-A-011 构建性能优化
• FB-21-EN-A-073 分层测试策略

参考资源：

• Vite HMR 文档
• Webpack Hot Module Replacement

口头回答版：

HMR 失效或变慢，常见原因有文件监听上限、构建配置问题、大依赖、自定义 loader 慢、网络代理等。排查时先看系统文件监听上限，再开 Vite 的 DEBUG=vite:hmr 看日志，检查有没有插件处理所有文件，有没有引入整个大库。优化可以排除不需要监听的目录、按需加载、用 ESM 版本、拆分路由、WSL 用原生文件系统。最好定期测一下本地 dev 的冷启动和热更新时间。

---

FB-21-CP-A-075：如何在不牺牲质量的前提下缩短 PR 合并周期？

题型：综合开放题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：代码审查、CI/CD、开发者体验、团队协作、工程效能 出现频率：高频 预计回答时长：5-8 分钟

题目描述： 团队反馈 PR 从创建到合并时间过长，影响迭代效率。请给出在保障代码质量的前提下缩短 PR 合并周期的方案。

参考答案：

核心要点：缩短 PR 周期需要并行化检查、优化 Code Review 流程、减少上下文切换和批量合并冲突，同时用自动化守住质量底线。

详细解释：

1. 加速 CI 反馈

   • 只运行受影响的测试和构建（affected tests）。
   • 使用远程缓存和增量构建，避免重复工作。
   • 将重型检查（E2E、全量测试）与轻量检查（lint、单元测试）分层运行。

2. 优化 Code Review

   • 控制 PR 粒度，建议每个 PR 不超过 400 行变更。
   • 明确 reviewer 指派规则，避免无人 review。
   • 使用代码所有权（CODEOWNERS）自动分配相关专家。
   • 推广“先 review 后优化”文化，避免反复返工。

3. 减少冲突和返工

   • 鼓励小步快跑、频繁 rebase，减少大规模合并冲突。
   • 在开发前对齐方案，用 RFC 或设计文档减少方向性返工。
   • 使用 Draft PR 提前收集反馈。

4. 自动化质量门禁

   • lint、类型检查、单元测试必须绿才能合并。
   • 用 SonarQube / Codecov 等工具自动发现潜在问题。
   • 对低风险变更启用自动合并（auto-merge）和 dependabot 自动合并。

最佳实践：

• 度量 PR 周期各阶段耗时，找到真正瓶颈。
• 设立 SLA：如 24 小时内必须有首次 review。
• 定期复盘长时间未合并的 PR，总结模式。

评分维度：

• CI 优化（30%）：能提到 affected tests、缓存、分层检查
• Review 流程（30%）：能说明 PR 粒度、reviewer 分配、CODEOWNERS
• 冲突与返工（25%）：能提到小 PR、对齐方案、Draft PR
• 自动化门禁（15%）：能说明质量门禁和 auto-merge 的合理使用

常见错误：

• 为求快而绕过代码审查或测试
• 只关注 CI 时长，忽略 review 等待和返工时间
• PR 过大，导致 review 质量下降

延伸追问：

• 如果业务压力导致 review 时间被压缩，你会如何取舍？
• 如何度量 PR 合并周期的改进效果？

相关题目：

• FB-21-CP-R-026 CI 反馈时间优化
• FB-21-EN-A-012 Git Hooks 自动化检查

参考资源：

• Google - Code Review Developer Guide
• GitHub - Best practices for pull requests

口头回答版：

缩短 PR 周期要几个方面一起抓。CI 上只跑受影响的测试，用远程缓存和增量构建，重的检查分层跑。Review 上控制 PR 粒度，用 CODEOWNERS 自动分配合适的人，设 24 小时内首次 review 的 SLA。开发前对齐方案，用 Draft PR 提前收集反馈，减少返工。质量门禁用 lint、类型检查、单元测试守住，低风险变更可以自动合并。关键要度量每个阶段耗时，找到真正的瓶颈。

---

FB-21-EN-A-076：如何设计前端项目的依赖升级和废弃策略？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：依赖管理、npm、安全、技术债、自动化 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 前端项目依赖容易堆积和过期，请设计一套依赖升级和废弃策略，兼顾安全、稳定性和开发效率。

参考答案：

核心要点：依赖策略应包含定期审计、分级升级、自动化提醒、灰度验证和废弃依赖替换机制，避免依赖成为安全和维护负担。

详细解释：

1. 依赖分级

   • 核心依赖：框架、构建工具，升级需充分测试和 RFC。
   • 通用依赖：工具库、组件库，按 SemVer 小版本定期升级。
   • 边缘依赖：一次性使用的库，评估是否有必要保留。

2. 升级流程

   • 定期审计：使用 npm audit、pnpm audit、Snyk、Dependabot 发现漏洞。
   • 自动化提醒：Dependabot / Renovate 自动提 PR，附带 changelog 摘要。
   • 分级验证：
     • patch/minor：CI 通过后可合并。
     • major：需要手动验证、灰度发布、影响面评估。
   • 废弃替换：对不再维护的依赖，制定替换计划和时间表。

3. 风险控制

   • 在 Monorepo 中先升级一个 pilot 项目验证。
   • 对关键路径依赖做回归测试和性能基准对比。
   • 保留回滚方案，发布后发现异常可快速降级。

最佳实践：

• 每月固定一次“依赖健康日”。
• 对 major 升级编写迁移指南和 codemod。
• 将安全漏洞修复优先级高于功能升级。

评分维度：

• 分级意识（30%）：能区分核心、通用、边缘依赖
• 流程设计（40%）：能覆盖审计、提醒、验证、替换、回滚
• 工具运用（30%）：能提到 Dependabot、Renovate、npm audit、Snyk

常见错误：

• 长期不升级，导致升级成本指数级增长
• 看到安全告警就盲目升级 major 版本
• 忽略 peer dependency 和子依赖的兼容性问题

延伸追问：

• 如何处理一个核心依赖不再维护的情况？
• 在 Monorepo 中，不同子项目依赖版本冲突怎么解决？

相关题目：

• FB-21-CO-B-070 技术债与 DX
• FB-21-EN-P-054 依赖安全扫描

参考资源：

• Dependabot 文档
• Renovate 文档

口头回答版：

依赖升级要分核心、通用、边缘三类管理。核心依赖升级要审慎，通用依赖按 SemVer 定期升，边缘依赖评估是否还要。流程上定期用 npm audit 或 Snyk 审计，Dependabot 自动提 PR，patch 和 minor CI 过了可以合，major 要手动验证和灰度。对废弃依赖要制定替换计划。每月可以设一个依赖健康日，安全漏洞优先修。

---

FB-21-SC-A-077：多个业务线共用组件库但需求冲突，如何设计治理机制？

题型：场景设计题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：组件库、Monorepo、团队协作、治理、Design System 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 公司多个业务线共用一个组件库，经常出现 A 业务改动了 B 业务不想要的特性，或各业务线重复提交相似组件。请设计一套治理机制。

参考答案：

核心要点：组件库治理需要明确所有权、建立 RFC 流程、分层设计 API、设立贡献规范，并用工具和指标保证演进可控。

详细解释：

1. 组织层面

   • 成立 Design System / 组件库委员会，由各业务线代表组成。
   • 明确组件库维护团队和组件 Owner，使用 CODEOWNERS。
   • 定期召开同步会，评审新增、修改和废弃提案。

2. 流程层面

   • RFC 机制：新增组件、破坏性变更、重大 API 调整需先写 RFC。
   • 贡献规范：明确提交 PR 前需补充文档、测试、示例和变更日志。
   • 影响面评估：改动前查询组件使用方，评估 break change 风险。
   • 版本策略：核心组件遵循 SemVer，破坏性变更走 major 版本。

3. 技术层面

   • 分层架构：基础组件（原子）保持通用，业务组件在各自包或层实现。
   • 可扩展点：基础组件提供 slots、render props 或配置化能力，减少直接 fork。
   • Monorepo 管理：业务组件和基础组件分 package，独立发布。
   • 使用统计：通过 AST 分析或埋点了解组件使用情况，指导治理。

4. 文化与激励

   • 认可并奖励跨业务线的贡献。
   • 把组件库质量纳入团队 KPI 或技术品牌活动。

最佳实践：

• 基础组件库只保留 80% 业务共需的能力，避免过度通用。
• 破坏性变更提供 codemod 和迁移周期。
• 定期清理低使用率组件，降低维护负担。

评分维度：

• 组织设计（30%）：能提到委员会、Owner、CODEOWNERS
• 流程规范（30%）：能说明 RFC、贡献规范、影响面评估、SemVer
• 技术架构（25%）：能说明分层、可扩展点、Monorepo、使用统计
• 文化激励（15%）：能提到跨团队贡献认可和激励

常见错误：

• 所有业务需求都塞进基础组件库，导致库越来越臃肿
• 缺乏 RFC 流程，改动随意
• 只关注开发，不关注组件上线后的使用和维护

延伸追问：

• 如果某个业务线坚持要一个完全定制化的组件，应该怎么做？
• 如何衡量组件库治理的效果？

相关题目：

• FB-21-SD-R-029 组件/文档/示例一体化工具链
• FB-21-SC-P-047 跨团队组件共享

参考资源：

• Design Systems Governance
• Storybook - Design Systems for Developers

口头回答版：

多业务线共用组件库，治理要从组织、流程、技术三方面做。组织上成立组件库委员会，明确 Owner 和 CODEOWNERS；流程上新组件和破坏性变更走 RFC，贡献要补文档测试，改动前评估影响面；技术上基础组件保持通用，业务组件分层或独立包，提供可扩展点减少 fork，用 Monorepo 独立发布。还要定期清理低使用率组件，奖励跨团队贡献。

---

FB-21-EN-A-078：如何实现前端工程配置的共享和版本管理？

题型：工程化题 难度：🟡 进阶 岗位层级：高级 面试知识域：21 开发者体验与工程效能 标签：前端工程化、配置管理、Monorepo、共享配置、工具链 出现频率：中频 预计回答时长：5-8 分钟

题目描述： 团队多个项目使用相似的 ESLint、Prettier、TypeScript、Commitlint 等配置。请设计一套共享配置方案，并说明版本管理策略。

参考答案：

核心要点：共享配置应打包成独立的 npm 包或 Monorepo 包，通过 extends 引用，并遵循 SemVer 独立发布，让各项目按需升级。

详细解释：

1. 配置共享方案

   • 独立配置包：将 ESLint、Prettier、TS、Commitlint 配置分别发布为 @org/eslint-config、@org/prettier-config 等。
   • 聚合配置包：提供一个 @org/configs 聚合包，方便新项目一键引入。
   • Monorepo 内部包：在 Monorepo 中作为 workspace package，其他子项目通过 workspace:* 引用。

2. 使用方式

   • ESLint：`extends: ["@org/eslint-config"]``。
   • Prettier："prettier": "@org/prettier-config"。
   • TypeScript："extends": "@org/tsconfig/base.json"。
   • Commitlint：extends: ["@org/commitlint-config"]。

3. 版本管理策略

   • 每个配置包独立 SemVer 版本。
   • minor：新增规则或放宽规则，可能产生 warning。
   • major：启用新的严格规则或移除旧规则，需配合迁移指南。
   • 使用很多于 1 年的 LTS 策略，给项目充分迁移时间。

4. 升级与通知

   • 通过内部 CLI 或 Renovate 自动检测配置包更新。
   • 提供 codemod 或迁移脚本处理 breaking change。
   • 在升级前提供 beta 版本让小范围项目试用。

最佳实践：

• 配置包里不要包含项目特定的路径或环境假设。
• 提供覆盖机制，允许项目在不 fork 配置包的情况下局部调整。
• 将配置包本身也纳入 CI 测试，确保发布后可用。

评分维度：

• 方案设计（40%）：能说明独立配置包、聚合包、Monorepo 内部包的优劣
• 使用方式（25%）：能给出 ESLint/Prettier/TS/Commitlint 的引用方式
• 版本管理（25%）：能说明 SemVer、major/minor 策略、LTS
• 升级机制（10%）：能提到自动检测、codemod、beta 试用

常见错误：

• 把配置直接复制到每个项目，导致升级困难
• 配置包更新过于激进，导致所有项目同时报错
• 配置包里包含项目特定路径，失去通用性

延伸追问：

• 如果某个项目需要临时关闭一条共享规则，如何优雅处理？
• 配置包的 breaking change 如何通知到所有使用方？

相关题目：

• FB-21-EN-A-013 TypeScript compilerOptions 取舍
• FB-21-EN-A-009 团队级项目模板

参考资源：

• ESLint Shareable Configs
• Prettier Configuration Sharing

口头回答版：

共享配置最好打包成 npm 包，比如 @org/eslint-config、@org/tsconfig，新项目可以单独引，也可以用一个聚合包。ESLint 用 extends，Prettier 用 prettier 字段，TS 用 extends。版本管理遵循 SemVer，独立发布，major 变更有迁移指南。升级时可以用 Renovate 自动检测，提供 codemod。配置包里不要放项目特定路径，允许项目局部覆盖。

---

深入题（6 道）

FB-21-SD-P-079：如何设计一个前端运行时性能监控与诊断平台？

题型：系统设计题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：性能监控、Web Vitals、可观测性、前端架构、诊断平台 出现频率：中频 预计回答时长：10-15 分钟

题目描述： 请设计一个前端运行时性能监控与诊断平台，能够采集、聚合、告警并辅助定位性能问题。

参考答案：

核心要点：平台应覆盖采集 SDK、数据上报、聚合分析、可视化诊断和告警闭环五个层面，兼顾低侵入、高可用和隐私合规。

详细解释：

1. 采集层

   • Web Vitals：LCP、INP、CLS、FCP、TTFB。
   • 自定义指标：首屏时间、白屏时间、API 耗时、资源加载时间、长任务。
   • 上下文信息：页面 URL、设备、网络、浏览器版本、发布版本、用户采样 ID。
   • 采集方式：PerformanceObserver、Performance Timing API、Long Tasks API、Resource Timing。

2. 上报层

   • 批量上报 + 压缩，优先使用 sendBeacon 和 fetch keepalive。
   • 采样策略：全量采集关键指标，详细诊断数据按用户或错误采样。
   • 失败重试与本地队列，避免丢失数据。

3. 聚合与分析层

   • 按版本、页面、设备、地域等维度聚合百分位数据。
   • 建立性能基线，检测异常波动。
   • 关联错误日志、发布事件和 A/B 实验。

4. 诊断与可视化

   • 提供趋势看板、瀑布图、热力图、单样本回溯。
   • 自动识别慢资源、长任务、布局抖动等模式。
   • 与 Source Map 结合，定位具体代码位置。

5. 告警与闭环

   • 基于 SLI/SLO 设定告警阈值，避免噪音。
   • 告警自动关联最近发布和实验变更。
   • 推动问题修复并验证回归。

最佳实践：

• SDK 要轻量，核心逻辑控制在几 KB 内。
• 采集数据要脱敏，避免收集用户敏感信息。
• 提供本地开发插件，让开发者实时查看性能数据。

评分维度：

• 采集设计（30%）：能覆盖 Web Vitals、自定义指标、上下文、API
• 上报与采样（20%）：能说明批量、压缩、采样、失败处理
• 聚合分析（20%）：能说明维度聚合、基线、异常检测
• 诊断可视化（15%）：能说明看板、瀑布图、Source Map 定位
• 告警闭环（15%）：能说明 SLI/SLO、发布关联、修复验证

常见错误：

• 采集所有指标全量上报，导致性能反噬
• 只关注平均值，忽略 P75/P95/P99
• 告警阈值固定，产生大量噪音或漏报

延伸追问：

• 如何在不影响页面性能的前提下采集 Long Tasks？
• 性能回归时，如何快速判断是代码变更还是网络波动导致？

相关题目：

• FB-21-CO-B-068 可观测性核心维度
• FB-21-SD-P-056 前端错误追踪与诊断平台

参考资源：

• Web Vitals
• MDN - Performance API

口头回答版：

前端性能监控平台要分采集、上报、聚合、诊断、告警五层。采集用 PerformanceObserver 拿 Web Vitals、资源耗时、长任务，带上页面、版本、设备上下文。上报要批量、压缩、采样，避免影响页面。聚合按页面、版本、设备看 P75/P95，建立基线。诊断用瀑布图、热力图、单样本回溯，结合 Source Map 定位代码。告警基于 SLI/SLO，关联发布事件，推动修复闭环。

---

FB-21-EN-P-080：大型前端项目如何设计模块联邦或微前端的构建协同？

题型：工程化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：微前端、Module Federation、构建工具、Monorepo、团队协作 出现频率：中频 预计回答时长：8-15 分钟

题目描述： 在大型前端项目采用微前端或 Module Federation 时，如何设计构建协同机制，保证独立部署与整体一致性？

参考答案：

核心要点：微前端构建协同需要在独立部署、依赖共享、版本兼容和运行时加载之间取得平衡；通过共享依赖、统一构建规范、版本契约和灰度机制降低集成风险。

详细解释：

1. 独立构建与部署

   • 每个微应用独立仓库或 Monorepo 中独立 package。
   • 独立 CI/CD，独立产物输出到统一 CDN 或注册中心。
   • 主应用通过运行时配置动态加载子应用。

2. 依赖共享策略

   • 共享核心依赖：React、Vue、React Router 等通过 Module Federation shared 或 import map 共享。
   • 版本兼容：使用 SemVer 范围，运行时使用满足所有子应用的最小兼容版本。
   • 兜底机制：无共享版本时允许子应用自包含，避免加载失败。

3. 构建规范统一

   • 统一构建工具版本和配置基线。
   • 统一产物格式（UMD / ESM / SystemJS）和命名规范。
   • 统一 Source Map 上传和版本号注入。

4. 版本契约与灰度

   • 主应用维护子应用版本映射表，支持按环境、用户、区域灰度。
   • 子应用发布新 major 版本需主应用显式升级。
   • 建立兼容性测试环境，发布前跑集成回归。

5. 开发体验

   • 本地开发支持独立启动和集成启动两种模式。
   • 提供微前端调试插件，查看加载的子应用、版本和依赖。
   • 错误隔离：子应用报错不影响主应用和其他子应用。

最佳实践：

• 共享依赖范围要精确，避免“共享所有”导致版本冲突。
• 子应用暴露的接口要稳定，减少主应用频繁适配。
• 监控子应用加载失败率，自动降级或告警。

评分维度：

• 独立部署（25%）：能说明独立构建、产物注册、运行时加载
• 依赖共享（25%）：能说明 shared、import map、版本兼容、兜底
• 构建规范（20%）：能说明统一工具、产物格式、Source Map
• 版本灰度（15%）：能说明版本映射、灰度、兼容性测试
• 开发体验（15%）：能说明本地开发模式、调试工具、错误隔离

常见错误：

• 过度共享依赖，导致版本冲突难以调试
• 子应用接口不稳定，主应用频繁报错
• 本地只测独立模式，忽略集成模式验证

延伸追问：

• Module Federation 2 与 1 在共享机制上有什么改进？
• 微前端架构下如何统一全局状态和路由？

相关题目：

• FB-21-SD-R-029 组件/文档/示例一体化工具链
• FB-21-SC-A-077 组件库治理机制

参考资源：

• Module Federation 文档
• Micro Frontends

口头回答版：

大型项目用微前端或 Module Federation，构建协同要平衡独立部署和一致性。每个子应用独立构建部署，产物放到统一注册中心，主应用动态加载。核心依赖通过 shared 或 import map 共享，按 SemVer 找兼容版本，没共享就兜底自包含。构建工具、产物格式、Source Map 要统一。主应用维护子应用版本映射，支持灰度，major 版本要显式升级。本地开发支持独立和集成两种模式，子应用报错要隔离。

---

FB-21-CP-P-081：如何构建数据驱动的 DX 改进闭环？

题型：综合开放题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：开发者体验、效能度量、数据驱动、持续改进、平台工程 出现频率：中频 预计回答时长：8-15 分钟

题目描述： 请描述如何通过数据驱动的方式持续改进开发者体验，并形成一个可落地的闭环。

参考答案：

核心要点：数据驱动的 DX 改进闭环包括定义指标、采集数据、发现问题、制定改进、实施验证和反馈迭代六个环节，最终形成可量化的工程文化。

详细解释：

1. 定义指标

   • 效率指标：构建时间、CI 时长、PR 合并周期、发布频率。
   • 质量指标：缺陷率、测试覆盖率、线上故障数、回滚率。
   • 体验指标：开发者 NPS、onboarding 时长、支持工单数、工具满意度。
   • 稳定性指标： flaky test 率、环境可用性、服务 SLA。

2. 采集与整合

   • 从 CI/CD、构建工具、代码仓库、错误监控、问卷中采集数据。
   • 建立统一的数据仓库或效能数据中台。
   • 关联发布事件、代码变更和指标波动。

3. 发现与诊断

   • 通过趋势图、同比环比、异常检测定位问题。
   • 结合定性访谈验证数据背后的真实痛点。
   • 识别高频阻塞点和高影响改进项。

4. 制定与实施改进

   • 按影响力和成本排序，优先做“高影响低成本”的改进。
   • 设定明确目标和退出条件，避免无限投入。
   • 小步快跑，先试点再推广。

5. 验证与反馈

   • 改进后对比 before/after 数据。
   • 通过问卷、访谈收集开发者主观感受。
   • 将成功经验沉淀为规范和工具，失败经验纳入复盘。

6. 持续运营

   • 每季度发布 DX 报告，向团队和管理层透明进展。
   • 设立 DX 大使或虚拟团队，持续收集反馈。

最佳实践：

• 指标不要过多，先聚焦 3-5 个北极星指标。
• 数据要与真实场景结合，避免唯指标论。
• 让业务团队也参与指标定义，增强认同感。

评分维度：

• 指标体系（30%）：能覆盖效率、质量、体验、稳定性多维度
• 数据采集（20%）：能说明多源采集和数据中台思路
• 诊断改进（25%）：能说明问题定位、优先级、试点推广
• 验证闭环（15%）：能说明 before/after、问卷反馈、复盘
• 持续运营（10%）：能说明 DX 报告、大使机制

常见错误：

• 只收集数据不行动，导致开发者失去信任
• 指标过多过杂，无法聚焦
• 忽视定性反馈，只看数字

延伸追问：

• 如何避免为了指标好看而做表面优化？
• 如果某个改进短期内指标没有提升，如何判断是否继续投入？

相关题目：

• FB-21-CP-P-021 DORA 与 SPACE
• FB-21-CP-P-055 前端团队工程效能度量

参考资源：

• DORA - Accelerate
• SPACE Framework

口头回答版：

数据驱动的 DX 改进要先定义指标，比如构建时间、CI 时长、PR 周期、缺陷率、开发者 NPS。然后多源采集数据，建立统一仓库。发现异常后结合访谈验证，按影响力和成本排序做改进，小步快跑、先试点。改进后对比 before/after，再收集反馈，形成闭环。关键是不要指标过多，要聚焦北极星指标，并且不能只收集不行动。

---

FB-21-PE-P-082：如何系统性地优化前端测试的执行速度和稳定性？

题型：性能优化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：前端测试、性能优化、稳定性、CI/CD、测试策略 出现频率：中频 预计回答时长：8-15 分钟

题目描述： 前端测试随着项目增长变得越来越慢、越来越不稳定。请给出系统性的优化方案。

参考答案：

核心要点：优化测试速度和稳定性需要从测试分层、并行执行、Mock 策略、环境隔离和 flaky 治理五个维度系统推进。

详细解释：

1. 测试分层与精简

   • 按测试金字塔减少 E2E 数量，增加单元和集成测试。
   • 只运行受变更影响的测试（affected tests）。
   • 删除无价值、重复或长期跳过的测试。

2. 并行与缓存

   • 单元测试按文件或 suite 分片并行执行。
   • 使用 Vitest / Jest 的 worker pool 和 shard 能力。
   • 对不依赖代码的测试输入做缓存。

3. Mock 与隔离

   • 使用 MSW 替代真实后端，避免网络不稳定。
   • Mock 定时器、随机数、日期等不可控因素。
   • 每个测试独立 setup/teardown，避免状态泄漏。

4. Flaky 测试治理

   • 建立 flaky test 登记和追踪机制。
   • 对 flaky 测试优先修复，临时跳过需标注原因和期限。
   • 引入重试机制但不要把重试当常态。

5. 环境一致性

   • CI 与本地使用相同 Node 版本和包管理器。
   • 使用固定浏览器版本或 Docker 化测试环境。
   • 控制资源竞争，避免并行任务互相影响。

最佳实践：

• 将测试耗时和 flaky 率纳入 CI 看板。
• 设立“flaky 测试零容忍”文化。
• 对慢测试定期进行 top N 分析并专项优化。

评分维度：

• 分层优化（25%）：能说明金字塔、affected tests、精简
• 并行缓存（20%）：能说明分片、worker、shard、缓存
• Mock 隔离（20%）：能说明 MSW、定时器、状态隔离
• Flaky 治理（20%）：能说明登记、修复、重试策略
• 环境一致性（15%）：能说明 Node、浏览器、资源竞争

常见错误：

• 只加机器不加治理，导致成本线性上升
• 用重试掩盖 flaky 问题
• 测试之间共享全局状态，导致随机失败

延伸追问：

• 如何设计一个自动检测 flaky 测试的系统？
• E2E 测试中如何处理第三方依赖的不稳定性？

相关题目：

• FB-21-EN-A-073 分层测试策略
• FB-21-CP-R-028 自动化测试 ROI

参考资源：

• Google - Flaky Tests
• Vitest Performance

口头回答版：

测试慢和不稳定要系统优化。分层上减少 E2E，只跑受影响的测试；并行上用 worker 和 shard；Mock 上替代真实后端和不可控因素，每个测试独立状态。Flaky 测试要登记、优先修，不能靠重试掩盖。CI 和本地环境要一致，Node、浏览器版本固定，避免资源竞争。还要把测试耗时和 flaky 率可视化，定期治理慢测试。

---

FB-21-SS-P-083：如何在业务高压下推动工程师文化和 DX 建设？

题型：软技能题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：工程师文化、DX、团队管理、技术领导力、变革管理 出现频率：中频 预计回答时长：5-10 分钟

题目描述： 业务需求紧张时，团队往往无暇顾及开发者体验和工程文化建设。请说明如何在高压环境下持续推进 DX。

参考答案：

核心要点：高压下推动 DX 需要把工程改进与业务目标对齐、用数据和案例证明价值、化整为零地落地，并通过激励机制形成正向循环。

详细解释：

1. 与业务目标对齐

   • 将 DX 改进翻译成业务语言：上线速度、故障率、支持成本。
   • 在业务OKR 中找到 DX 能支撑的指标，如“Q3 发布 X 个需求”。
   • 选择业务痛点最明显的环节切入，如一触即发的构建慢问题。

2. 化整为零

   • 把大改进拆成多个 Quick Win，每次只占用少量迭代时间。
   • 利用技术债预算（如 20% 迭代时间）持续投入。
   • 在需求间隙或稳定性窗口期集中推进较重的改造。

3. 数据与案例驱动

   • 建立基线，展示改进前后的效率对比。
   • 用具体项目案例说明 DX 投入如何减少了故障或加快了上线。
   • 定期向团队和leader汇报，保持透明度。

4. 激励机制

   • 认可和奖励在 DX 改进中做出贡献的成员。
   • 把工程实践纳入绩效和晋升考量。
   • 设立 DX Hackathon、技术分享等轻松形式。

5. 建立同盟

   • 找到业务线中的痛点代表，让他们成为 DX 推动的盟友。
   • 与产品、测试、运维建立跨团队共识。

最佳实践：

• 不要一次性要求大量资源，先证明小改进的价值。
• 让业务负责人也参与 DX 决策，增强 ownership。
• 保持耐心，文化建设是长期工程。

评分维度：

• 业务对齐（30%）：能把 DX 与业务目标、OKR 结合
• 落地策略（25%）：能说明 Quick Win、技术债预算、窗口期
• 数据案例（20%）：能说明基线、对比、案例汇报
• 激励机制（15%）：能说明认可、绩效、Hackathon
• 同盟建设（10%）：能说明跨团队共识和痛点代表

常见错误：

• 脱离业务讲技术，导致资源申请困难
• 一次性推动过多变革，引发团队抵触
• 只在口头上重视 DX，不投入实际时间

延伸追问：

• 如果业务负责人明确拒绝为 DX 投入时间，你会怎么办？
• 如何衡量工程师文化建设的效果？

相关题目：

• FB-21-SS-P-020 推动统一 DX 平台
• FB-21-SS-R-030 向管理层证明 DX 价值

参考资源：

• Accelerate - Nicole Forsgren
• The Business Value of Developer Experience

口头回答版：

业务高压下推 DX，关键是把工程改进和业务目标对齐，比如构建快了能支持更多需求上线。把大改进拆成小 Quick Win，利用技术债预算或稳定窗口逐步做。用数据说话，建立 before/after 对比，定期汇报。还要激励贡献者，把工程实践纳入绩效，找业务线里的痛点代表做盟友。不要一次性推太多，先证明小价值再要资源。

---

FB-21-EN-P-084：如何设计前端资产的发现与复用机制？

题型：工程化题 难度：🔴 深入 岗位层级：专家 面试知识域：21 开发者体验与工程效能 标签：组件复用、资产发现、Design System、Monorepo、平台工程 出现频率：中频 预计回答时长：8-15 分钟

题目描述： 请设计一套前端资产（组件、页面模板、业务区块）的发现与复用机制，提升跨团队复用率。

参考答案：

核心要点：前端资产复用机制应覆盖资产生产、注册、发现、消费、反馈和治理六个环节，并通过门户、CLI 和 IDE 插件降低使用门槛。

详细解释：

1. 资产生产

   • 定义资产标准：目录结构、命名规范、文档、示例、测试、版本。
   • 提供脚手架快速创建符合标准的资产。
   • 支持多种资产类型：原子组件、业务组件、页面模板、Hooks、工具函数。

2. 资产注册

   • 建立资产注册中心（Registry），记录资产元数据、版本、依赖、使用方。
   • 支持从 npm、Monorepo、Git 仓库自动同步资产信息。
   • 每个资产有明确 Owner、状态（stable/deprecated/experimental）。

3. 资产发现

   • 门户站点：支持搜索、分类、标签、使用统计、示例预览。
   • IDE 插件：在编辑器中直接搜索和插入组件。
   • CLI 工具：通过命令行搜索、安装、更新资产。

4. 资产消费

   • 提供 npm 安装、Monorepo 引用、代码片段复制等多种消费方式。
   • 自动生成 TypeScript 类型、使用文档和 changelog。
   • 支持按需引入和 tree-shaking。

5. 反馈与治理

   • 收集使用方评分、issue、需求，指导资产迭代。
   • 定期分析资产使用率，清理低价值资产。
   • 对废弃资产提供迁移路径和 codemod。

最佳实践：

• 资产标准要先统一，否则门户只是信息堆砌。
• 示例代码必须可运行，最好集成 Storybook 或 CodeSandbox。
• 把资产复用率作为团队和平台运营的北极星指标之一。

评分维度：

• 生产标准（20%）：能说明资产标准和脚手架
• 注册管理（20%）：能说明 Registry、元数据、Owner、状态
• 发现方式（25%）：能覆盖门户、IDE、CLI 三种发现渠道
• 消费体验（20%）：能说明安装、文档、类型、按需引入
• 反馈治理（15%）：能说明评分、使用率、清理、迁移

常见错误：

• 只建门户不建标准，导致资产质量参差不齐
• 忽略消费侧体验，发现资产后难以安装和使用
• 不复盘使用率，门户变成资产墓地

延伸追问：

• 如何激励业务团队把可复用组件贡献到资产平台？
• 资产版本升级时，如何通知和协助使用方迁移？

相关题目：

• FB-21-SD-R-029 组件/文档/示例一体化工具链
• FB-21-SD-R-059 前端资产复用平台

参考资源：

• Backstage Software Catalog
• Storybook Component Encyclopedia

口头回答版：

前端资产复用要覆盖生产、注册、发现、消费、反馈、治理。生产时定义标准和脚手架；注册到资产中心，记录元数据、版本、Owner、状态；发现方式要有门户站点、IDE 插件、CLI；消费时提供 npm 安装、自动生成文档和类型、支持按需引入。还要收集使用反馈，定期清理低使用率资产，废弃时给迁移路径。关键是标准先统一，门户才有意义。

---

架构题（41 道）

FB-21-SD-R-085：设计一个面向多 BU 的前端研效中台，核心模块和运营策略是什么？

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：平台工程、研效中台、前端架构、组织协同、效能度量 出现频率：低频 预计回答时长：15-30 分钟

题目描述： 请为一家拥有多个业务线（BU）的公司设计一个前端研发效能中台，提升跨 BU 的协同效率和工程能力复用。

参考答案：

核心要点：多 BU 前端研效中台应以“能力复用、数据驱动、自助服务”为核心，通过统一工具链、共享资产、度量体系和治理机制，减少重复建设和效率损耗。

详细解释：

1. 核心模块

   • 统一脚手架与模板：提供多技术栈（React/Vue/小程序）项目模板，内置规范、CI、测试、文档。
   • 组件与资产市场：跨 BU 共享组件、页面模板、Hooks、工具库，支持搜索、版本管理和使用统计。
   • 构建与发布平台：统一 CI/CD、制品仓库、灰度发布、回滚、多环境管理。
   • 质量门禁平台：集成 lint、类型检查、测试、安全扫描、覆盖率，统一门禁策略。
   • 可观测性与诊断：错误监控、性能监控、日志聚合、链路追踪。
   • 效能数据中台：采集构建、CI、PR、发布、质量数据，生成看板和报告。
   • 开发者门户：一站式入口，聚合文档、工具、资产、数据、支持渠道。

2. 组织与治理

   • 设立平台工程团队，由各 BU 派驻代表参与治理委员会。
   • 制定 RFC 流程、贡献规范、SLA 和服务目录。
   • 明确平台与 BU 的边界：平台提供基础能力，BU 负责业务定制。

3. 运营策略

   • 从痛点切入：先解决构建慢、发布难、组件重复等共性问题。
   • Quick Win 证明价值：早期用缓存、统一 lint 等低成本改进建立信任。
   • 数据透明：每季度发布研效报告，展示各 BU 指标和改进效果。
   • 激励贡献：对贡献组件、工具和最佳实践的 BU 给予认可和资源倾斜。
   • 渐进式推广：先在 1-2 个 BU 试点，成熟后推广到全公司。

最佳实践：

• 平台能力要可插拔，允许 BU 按需选择和扩展。
• 不要一刀切强制所有 BU 使用同一技术栈。
• 建立用户反馈渠道，平台团队像服务客户一样服务 BU。

评分维度：

• 模块设计（35%）：能覆盖脚手架、资产市场、构建发布、质量、可观测、数据中台、门户
• 组织治理（25%）：能说明平台团队、治理委员会、RFC、SLA
• 运营策略（25%）：能说明痛点切入、Quick Win、数据透明、激励、推广
• 边界意识（15%）：能说明平台与 BU 的边界、可插拔、不强推统一栈

常见错误：

• 平台设计过于理想化，忽视 BU 差异和迁移成本
• 只做工具不做运营，导致采用率低
• 强制所有 BU 使用同一技术栈，引发抵触

延伸追问：

• 如何衡量研效中台的投资回报率？
• 当 BU 需求与平台通用能力冲突时，如何决策？

相关题目：

• FB-21-SD-R-061 前端研发效能数据中台
• FB-21-SD-R-024 百人前端团队平台工程体系

参考资源：

• Platform Engineering
• Team Topologies

口头回答版：

多 BU 前端研效中台核心要做到能力复用、数据驱动、自助服务。模块上要有统一脚手架、组件资产市场、构建发布平台、质量门禁、可观测、效能数据中台和开发者门户。组织上设平台工程团队和治理委员会，明确平台和 BU 边界。运营上从共性问题切入，先拿 Quick Win 证明价值，数据透明，激励贡献，逐步推广。平台能力要可插拔，不能强制统一技术栈。

---

FB-21-CP-R-086：如何制定前端技术栈的长期演进和退役策略？

题型：综合开放题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：技术演进、技术栈、架构决策、风险管理、退役策略 出现频率：低频 预计回答时长：10-15 分钟

题目描述： 请说明如何为前端技术栈制定长期演进路线，并对老旧技术进行有序退役。

参考答案：

核心要点：技术栈演进应基于业务需求、技术趋势、团队能力和维护成本制定路线；退役策略要明确触发条件、替代方案、迁移路径和风险兜底。

详细解释：

1. 演进路线制定

   • 输入收集：业务规划、技术趋势、开发者反馈、安全漏洞、性能瓶颈。
   • 现状评估：绘制技术雷达，标记采纳、试验、评估、退役项。
   • 目标设定：定义 1 年、3 年技术目标，如统一构建工具、升级框架版本。
   • 路线图：分阶段实施，与业务节奏对齐，预留迁移窗口。

2. 技术引入决策

   • 使用 RFC 流程评估新技术：问题、方案、成本、风险、试点计划。
   • 设定试验期、评估指标和退出条件。
   • 避免“追新”，优先选择生态成熟、团队能掌控的技术。

3. 技术退役策略

   • 退役标准：官方停止维护、安全漏洞无法修复、招聘困难、维护成本过高。
   • 替代方案：明确迁移目标技术，评估功能兼容性和性能差异。
   • 迁移路径：制定分阶段迁移计划，优先迁移高风险或高价值项目。
   • 兜底机制：保留回滚方案，关键老系统设维护窗口。
   • 知识转移：文档化、培训、codemod，降低迁移门槛。

4. 风险与沟通

   • 与业务方对齐迁移成本和收益。
   • 建立技术委员会做最终决策。
   • 定期 review 技术雷达和路线图。

最佳实践：

• 技术栈不要过度发散，控制“试验中”技术的数量。
• 老技术退役要温柔，避免一次性大规模重写。
• 把技术演进纳入 OKR 或技术预算。

评分维度：

• 演进规划（30%）：能说明输入、评估、目标、路线图
• 引入决策（20%）：能说明 RFC、试点、评估指标
• 退役策略（30%）：能说明标准、替代、迁移、兜底、知识转移
• 风险沟通（20%）：能说明业务对齐、技术委员会、定期 review

常见错误：

• 技术栈频繁变更，团队疲于迁移
• 老技术长期不退役，维护成本累积
• 引入新技术只考虑技术先进性，忽略生态和团队能力

延伸追问：

• 如果核心业务系统依赖一个即将退役的框架，你会如何推进迁移？
• 如何避免“新技术试点后烂尾”？

相关题目：

• FB-21-CP-R-064 前端工程化体系持续演进
• FB-21-CP-P-050 新技术引入评估

参考资源：

• ThoughtWorks Technology Radar
• The Economics of Software Quality

口头回答版：

前端技术栈演进要结合业务需求、技术趋势、团队能力和维护成本。先评估现状，画技术雷达，定 1 年、3 年目标，分阶段做。引入新技术走 RFC，明确试点和退出条件。退役老技术要有标准：停止维护、安全漏洞、维护成本太高。退役时明确替代方案、分阶段迁移、保留回滚，还要做 codemod 和培训。关键是别追新，也别让老技术一直拖着不退役。

---

FB-21-SD-R-087：设计一个支持 A/B 实验和灰度发布的前端发布与回滚平台。

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：A/B 测试、灰度发布、发布平台、前端架构、回滚 出现频率：低频 预计回答时长：15-30 分钟

题目描述： 请设计一个前端发布平台，支持 A/B 实验、灰度发布、快速回滚，并保证发布过程的安全和可观测。

参考答案：

核心要点：平台应通过流量控制、版本管理、实验配置、发布编排和监控告警，实现前端发布从“一刀切”到“可控渐进”的转变。

详细解释：

1. 版本与产物管理

   • 每次构建生成唯一版本号和产物包，存储到对象存储或 CDN。
   • 维护版本元数据：commit、构建时间、依赖版本、Source Map、变更集。
   • 支持版本回滚到任意历史版本。

2. 流量控制与灰度

   • 按用户 ID、地区、设备、UA、cookie 等维度分流。
   • 支持百分比灰度：1% -> 5% -> 20% -> 100%。
   • 提供金丝雀环境，先内部用户验证再外发。
   • 与网关/CDN 边缘计算配合，实现请求级流量调度。

3. A/B 实验

   • 实验配置中心管理实验变量、分组策略、目标指标。
   • 前端 SDK 获取分组并上报埋点。
   • 支持互斥实验、正交实验和实验优先级。
   • 实验结果自动统计，达标后全量，未达标自动下线。

4. 发布编排

   • 发布流水线：构建 -> 质量门禁 -> 预发 -> 灰度 -> 全量。
   • 每个阶段有自动或人工审批。
   • 支持一键暂停、加速、回滚。

5. 可观测与回滚

   • 实时监控错误率、性能指标、业务指标。
   • 设定自动回滚阈值：错误率突增、核心指标下跌。
   • 回滚操作秒级生效，切换到稳定版本。

最佳实践：

• 灰度和实验要分离配置，避免互相干扰。
• 发布前进行影子流量或预发压测。
• 保留 last known good 版本作为默认回滚目标。

评分维度：

• 版本管理（20%）：能说明版本号、产物、元数据、Source Map
• 灰度流量（20%）：能说明分流维度、百分比、金丝雀、网关/CDN
• A/B 实验（20%）：能说明实验配置、分组、埋点、互斥、统计
• 发布编排（15%）：能说明流水线、门禁、审批、暂停回滚
• 可观测回滚（25%）：能说明监控指标、自动阈值、秒级回滚

常见错误：

• 灰度和 A/B 实验配置混为一谈
• 没有自动回滚机制，问题发现后响应慢
• 忽略前端资源缓存导致的版本不一致

延伸追问：

• 前端灰度发布时如何处理浏览器缓存和 CDN 缓存？
• 多页面应用和 SPA 在灰度策略上有什么不同？

相关题目：

• FB-21-SD-R-057 多云部署前端发布平台
• FB-21-SD-R-061 前端研发效能数据中台

参考资源：

• Feature Flags by Martin Fowler
• Netflix - A/B Testing at Scale

口头回答版：

前端发布平台要支持 A/B 实验和灰度发布。版本产物要唯一编号，存到 CDN，支持回滚。灰度按用户、地区、设备等维度分流，百分比逐步放大，还可以走金丝雀。A/B 实验有配置中心管分组和指标，前端 SDK 拿分组并埋点。发布流水线要经过质量门禁、预发、灰度、全量，支持一键暂停和回滚。监控错误率、性能、业务指标，触发阈值自动回滚。

---

FB-21-SS-R-088：作为前端技术负责人，如何构建可传承的技术决策机制？

题型：软技能题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：技术决策、架构治理、知识传承、团队协同、技术领导力 出现频率：低频 预计回答时长：10-15 分钟

题目描述： 请说明如何建立一套可持续、可传承的技术决策机制，避免决策依赖少数个人或随时间流失。

参考答案：

核心要点：可传承的技术决策机制需要明确决策主体、标准化决策流程、沉淀决策记录、培养决策文化，并通过治理组织持续演进。

详细解释：

1. 决策主体分层

   • 个人决策：低风险、影响范围小的事项，由一线工程师或 Owner 决定。
   • 团队决策：影响一个团队的事项，通过团队技术讨论决定。
   • 委员会决策：跨团队、长期影响、重大技术选型，通过技术委员会或架构评审决定。

2. 标准化流程

   • RFC 机制：重大决策必须先写 RFC，包含背景、方案、影响、风险、回滚计划。
   • 评审模板：统一评审维度，如成本、风险、可维护性、团队能力、业务契合度。
   • 决策记录（ADR）：每个重大决策形成 Architecture Decision Record，存入知识库。
   • 时限机制：明确评审周期，避免决策久拖不决。

3. 沉淀与传承

   • ADR 要包含决策背景、当时约束、被选方案、最终选择及原因。
   • 定期 review 历史决策，标记过时或需要重新评估的 ADR。
   • 新人 onboarding 包含技术决策历史学习。

4. 文化与培养

   • 鼓励一线工程师参与 RFC 和评审，培养决策能力。
   • 对决策质量进行复盘，不追责但总结教训。
   • 建立技术导师制，让资深人员带动决策能力传递。

最佳实践：

• 决策权要分散但边界清晰，避免所有事情都上升到委员会。
• ADR 与代码仓库放在一起，随代码一起演进。
• 用“同意即合并”或“明确反对才阻止”的原则提升效率。

评分维度：

• 决策分层（25%）：能说明个人、团队、委员会不同层级的决策范围
• 流程标准（30%）：能说明 RFC、评审模板、ADR、时限
• 沉淀传承（25%）：能说明 ADR 内容、定期 review、新人学习
• 文化培养（20%）：能说明参与机制、复盘、导师制

常见错误：

• 所有决策都依赖技术负责人个人拍板
• ADR 只写结论不写背景和取舍
• 决策流程过于繁琐，导致效率低下

延伸追问：

• 当委员会成员意见不一致时，如何做出最终决策？
• 如何让一线工程师愿意写 RFC 并参与评审？

相关题目：

• FB-21-SD-R-024 百人前端团队平台工程体系
• FB-21-CP-R-064 前端工程化体系持续演进

参考资源：

• Architecture Decision Records
• RFC Process at Rust

口头回答版：

可传承的技术决策机制要分层次：小事 Owner 定，团队事讨论定，大事走技术委员会。重大决策用 RFC，包含背景、方案、风险、回滚，评审用统一模板。决策后要写 ADR 记录背景和取舍，存在知识库里，定期 review。还要培养团队决策能力，让大家参与 RFC 和评审，复盘决策质量。ADR 最好和代码放一起，随项目演进。

---

FB-21-SD-R-089：设计一个前端工程化的“即服务”（DXaaS）平台。

题型：系统设计题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：DXaaS、平台工程、开发者体验、自助服务、前端架构 出现频率：低频 预计回答时长：15-30 分钟

题目描述： 请设计一个 Developer Experience as a Service（DXaaS）平台，让前端团队可以像使用云服务一样使用工程化能力。

参考答案：

核心要点：DXaaS 平台将脚手架、构建、测试、发布、监控、文档等工程能力服务化，通过 API、CLI 和门户为开发者提供自助、可度量、可扩展的工程支持。

详细解释：

1. 服务理念

   • 把工程化能力当作产品，有明确的服务目录、SLA 和用户支持。
   • 开发者自助获取能力，无需了解底层实现细节。
   • 平台团队对能力可用性、性能、易用性负责。

2. 核心能力层

   • 项目即服务：一键创建项目，选择技术栈、模板、CI/CD。
   • 构建即服务：远程构建、缓存、分布式任务调度。
   • 测试即服务：按需测试环境、并行测试、视觉回归服务。
   • 发布即服务：灰度发布、A/B 实验、回滚、多环境管理。
   • 质量即服务：lint、类型检查、安全扫描、覆盖率报告。
   • 可观测即服务：错误、性能、日志、链路统一接入。
   • 文档即服务：自动生成项目文档、API 文档、示例站点。

3. 接入方式

   • CLI：dx create、dx build、dx deploy 等命令。
   • Web Portal：可视化服务目录、项目看板、效能数据。
   • IDE 插件：在编辑器内直接调用平台能力。
   • API：供其他系统和自动化流程集成。

4. 平台运营

   • 服务目录明确每个能力的使用方式、Owner、SLA。
   • 收集 NPS、使用频率、故障工单，持续优化。
   • 提供多租户隔离，支持不同 BU 的定制需求。

5. 架构要点

   • 能力模块化、插件化，便于独立演进。
   • 统一身份认证和权限管理。
   • 事件驱动，支持能力间的联动（如构建完成触发测试）。

最佳实践：

• 不要一次性上线所有能力，按需求优先级迭代。
• 平台能力要有明确的退出和替代方案。
• 让开发者参与产品设计，避免平台团队闭门造车。

评分维度：

• 服务理念（20%）：能把工程化能力当作服务，强调自助和 SLA
• 能力覆盖（30%）：能覆盖项目、构建、测试、发布、质量、可观测、文档
• 接入方式（20%）：能说明 CLI、Portal、IDE、API
• 平台运营（15%）：能说明服务目录、NPS、多租户
• 架构设计（15%）：能说明模块化、插件化、事件驱动、权限

常见错误：

• 把 DXaaS 简单理解为工具集合，忽视服务化运营
• 平台能力过于封闭，不允许 BU 定制
• 忽略开发者真实需求，平台使用率低下

延伸追问：

• DXaaS 平台和传统内部工具平台有什么区别？
• 如何防止平台能力成为新的技术债？

相关题目：

• FB-21-SD-R-085 多 BU 前端研效中台
• FB-21-SD-R-061 前端研发效能数据中台

参考资源：

• Platform Engineering
• Internal Developer Platforms

口头回答版：

DXaaS 是把工程化能力当服务做，让开发者自助使用。核心能力包括项目创建、远程构建、测试环境、灰度发布、质量门禁、可观测、文档自动生成。接入方式有 CLI、Web 门户、IDE 插件和 API。平台要有服务目录、SLA、Owner，收集 NPS 和使用数据持续优化。架构上要模块化、插件化、事件驱动，支持多租户隔离。关键是按需求优先级迭代，让开发者参与设计。

---

FB-21-CP-R-090：如何在企业并购或技术整合中保障开发者体验不降级？

题型：综合开放题 难度：⚫ 架构 岗位层级：架构师 面试知识域：21 开发者体验与工程效能 标签：技术整合、并购、开发者体验、变革管理、前端架构 出现频率：低频 预计回答时长：10-15 分钟

题目描述： 企业在并购或部门整合后，往往会出现多套技术栈、工具和流程。请说明如何在这样的背景下保障甚至提升开发者体验。

参考答案：

核心要点：技术整合中保障 DX 需要以“先共存、再融合、最后统一”的节奏推进，尊重原有团队习惯，用数据和业务价值驱动决策，并提供充分的迁移支持。

详细解释：

1. 现状评估与尊重

   • 全面梳理两套技术栈、工具链、发布流程和团队文化。
   • 识别各自优势和痛点，避免一上来就否定某一方。
   • 与双方团队充分沟通，理解历史原因和约束。

2. 制定整合原则

   • 业务连续性优先：整合不应影响线上业务和用户。
   • 最小必要统一：先统一影响协作的关键环节，如代码仓库、CI/CD、组件库。
   • 数据驱动：用构建时间、发布频率、故障率等数据指导取舍。
   • 渐进式：分阶段推进，给团队适应和反馈时间。

3. 关键整合领域

   • 代码与仓库：选择合适的 Monorepo 或多仓库策略，统一权限和分支模型。
   • 工具链：评估两套构建工具、测试框架、代码规范，选择综合最优方案或保留双轨。
   • 组件与设计：统一 Design Token 和基础组件，业务组件允许差异。
   • 发布与运维：统一发布平台和可观测体系。
   • 文档与知识：整合文档站点，保留历史 ADR 和 RFC。

4. 迁移支持

   • 提供迁移指南、培训、工作坊和一对一支持。
   • 开发 codemod 和自动化迁移脚本。
   • 设立过渡期，允许旧方案在一定时间内并行运行。
   • 建立反馈渠道，及时调整整合策略。

5. 文化与沟通

   • 明确整合后的共同目标和愿景。
   • 让双方代表参与技术委员会和决策。
   • 庆祝早期成功，缓解整合焦虑。

最佳实践：

• 不要强制“一刀切”，尤其不要简单要求弱势方完全服从强势方。
• 设立整合专项组，专职推动和协调。
• 把 DX 指标纳入整合成功的衡量标准。

评分维度：

• 节奏把控（25%）：能说明共存、融合、统一的渐进节奏
• 整合原则（25%）：能说明业务连续、最小必要、数据驱动、渐进
• 关键领域（25%）：能覆盖代码、工具链、组件、发布、文档
• 迁移支持（15%）：能说明指南、培训、codemod、过渡期、反馈
• 文化沟通（10%）：能说明共同目标、代表参与、庆祝成功

常见错误：

• 强行统一技术栈，导致团队士气低落
• 忽视原有系统的历史原因和约束
• 整合过程中业务中断或发布节奏混乱

延伸追问：

• 如果两套技术栈各有优势，如何决策保留哪一套？
• 整合过程中出现关键人才流失，如何应对？

相关题目：

• FB-21-SD-R-089 DXaaS 平台
• FB-21-SS-R-088 技术决策机制

参考资源：

• M&A Integration Best Practices
• Team Topologies

口头回答版：

企业并购或整合时，技术栈和流程会冲突。保障 DX 要先共存、再融合、最后统一。先评估两套方案的优势和痛点，不要一上来否定某一方。整合原则：业务连续优先、最小必要统一、数据驱动、渐进推进。关键先统一代码仓库、CI/CD、基础组件和发布平台。迁移时给指南、培训、codemod 和过渡期。让双方代表参与决策，设共同目标，缓解焦虑。不要强制一刀切。

---

FB-21-CO-B-071：Cypress 组件测试的执行模型与在 CI 中的耗时度量方法

题型：概念题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：Cypress、效能度量 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 请解释 Cypress 的测试执行模型，并说明在 CI 流水线中如何度量组件/端到端测试的耗时与稳定性。

参考答案：

核心要点：Cypress 在浏览器内部运行测试代码，通过命令队列与自动重试机制控制执行；CI 中应结合 reporter、Cypress Cloud 和自定义指标度量单条用例耗时与 flaky 率。

详细解释：

1. 执行模型

   • Cypress 的测试代码与被测应用运行在同一个浏览器标签页内，由 Cypress Test Runner 注入并驱动。
   • 命令采用链式队列：每个命令进入队列后，Cypress 会在默认超时（如 4s）内反复重试断言，直到通过或超时。
   • 每条命令前后会捕获 DOM 快照，支持 Time Travel 调试，但会占用内存并影响 CI 资源。

2. CI 中度量耗时

   • 使用 reporter: 'junit' 或 cypress-multi-reporters 输出每个 spec 和 it 的耗时。
   • 通过 cypress run --record 上传到 Cypress Cloud，查看历史趋势、并行分发和瓶颈 spec。
   • 在 CI 日志中采集 spec 开始/结束时间戳，写入 Prometheus/InfluxDB 建立趋势图。

3. 稳定性度量

   • 收集 flaky tests 数量与重跑次数；将 flaky 用例打上标签并同步到 issue tracker。
   • 监控视频回放大小和截图数量，避免 CI 存储膨胀。

4. 优化 DX

   • 优先使用 Cypress Component Testing 替代部分 E2E，缩短反馈环。
   • CI 中按 spec 历史耗时排序并行分发；缓存 ~/.cache/Cypress 二进制避免重复下载。

评分维度：

• 执行模型准确（40%）：能说明浏览器内运行、命令队列、自动重试
• CI 度量方法（35%）：能说出 JUnit/Cypress Cloud、单条用例耗时、稳定性指标
• 优化实践（25%）：能提到组件测试、并行分发、缓存

常见错误：

• 把 Cypress 当成纯 Node 脚本运行，忽略浏览器内架构
• 只统计总耗时，不拆分 spec/用例级别
• 忽略视频与快照对 CI 存储和内存的影响

延伸追问：

• Cypress 的自动重试机制如何影响断言写法？
• 你如何将 Cypress 的 flaky 测试结果反馈给开发流程？

参考资源：

• Cypress How It Works
• Cypress CI Guide

口头回答版：

Cypress 的测试跑在浏览器里，通过 Runner 注入测试脚本，命令会进入队列并自动重试直到超时。CI 里可以用 JUnit reporter 或 Cypress Cloud 看每个 spec 和用例耗时，还要关注 flaky 次数。优化时多用组件测试、并行跑 spec、缓存 Cypress 二进制。

---

FB-21-SC-B-001：如何为前端构建流水线设计可观测性方案以持续优化构建性能

题型：场景设计题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：可观测性、构建性能 出现频率：低频 预计回答时长：3-5 分钟

题目描述： 团队使用 Vite/Webpack 构建前端应用，本地开发和 CI 中经常出现构建耗时波动。请设计一套可观测性方案，持续采集、展示和告警构建性能指标。

参考答案：

核心要点：构建可观测性应先定义覆盖安装、构建、HMR、Lint、缓存和产物体积的指标，再通过 CI 脚本、构建工具插件和看板实现采集、展示与告警闭环。

详细解释：

1. 指标定义

   • 安装耗时：pnpm/npm install 时间。
   • 冷启动耗时：dev server ready 时间。
   • 生产构建耗时：vite build / webpack --mode=production 总时间。
   • HMR 耗时：保存文件到浏览器更新的端到端时间。
   • 产物体积：总包体积、首屏 chunk、各路由 lazy chunk。
   • 缓存命中率：Turborepo / webpack persistent cache / Vite 缓存命中情况。
   • Lint/类型检查耗时：ESLint、tsc 单独耗时。

2. 采集方式

   • 在 package.json scripts 中包装时间戳命令，输出结构化 JSON。
   • Vite：使用 DEBUG=vite:resolve 和 vite --profile 定位解析瓶颈。
   • Webpack：使用 speed-measure-webpack-plugin 和 webpack-bundle-analyzer。
   • CI：通过 GITHUB_STEP_SUMMARY 或 GitLab artifacts 输出关键指标。

3. 存储与展示

   • 将指标写入 Prometheus/Grafana 或 InfluxDB；在团队看板展示趋势图，支持按项目/分支/提交下钻。

4. 告警与 SLO

   • 设置构建耗时 P95 基线，超过阈值时触发企业微信/Slack 告警。
   • 对缓存命中率下降、产物体积突增设置告警。

5. 闭环优化

   • 每周 Review Top 5 最慢构建，关联 PR 制定优化任务；将构建耗时纳入团队 OKR。

评分维度：

• 指标完整性（35%）：覆盖安装、构建、HMR、缓存、Lint 等维度
• 采集与展示方案（35%）：能给出 CI 输出、日志解析、看板工具
• 运营闭环（30%）：能说明告警阈值、Review 机制、OKR 关联

常见错误：

• 只采集总耗时，无法定位是哪个 loader 或依赖导致波动
• 把构建日志直接当指标，不做结构化解析
• 缺少基线，告警阈值拍脑袋

延伸追问：

• 如何在本地开发阶段采集 HMR 耗时而不影响开发者体验？
• 如果缓存命中率突然下降，你会从哪些方向排查？

参考资源：

• Webpack Build Performance
• Vite Performance

口头回答版：

我会先定义关键指标：安装、冷启动、构建、HMR、产物体积和缓存命中率。CI 里用脚本包装输出到 step summary，Vite 开 debug profile，Webpack 用 speed-measure。数据存到 Prometheus/Grafana，设 P95 基线告警，然后每周 Review 最慢的构建并落到优化任务。

---

FB-21-PE-B-001：平台工程团队如何度量和优化 pnpm 依赖安装性能

题型：性能优化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：平台工程、pnpm 出现频率：低频 预计回答时长：3-5 分钟

题目描述： 在包含数十个 package 的 Monorepo 中，pnpm install 在 CI 和本地均出现明显抖动。请说明排查思路和可落地的优化手段。

参考答案：

核心要点：pnpm 安装优化要先度量 lockfile 解析、网络、store 写入和链接耗时，再通过缓存、hoist 策略、安装范围控制等手段降低成本。

详细解释：

1. 度量指标

   • lockfile 解析耗时、网络请求耗时、内容可寻址存储写入耗时。
   • 硬链接/符号链接数量、peer dependency 解析次数。

2. 启用 side-effects-cache

   • pnpm config set side-effects-cache true，避免重复执行 postinstall。

3. 调整 hoist 策略

   • 对构建工具类项目可设置 node-linker=hoisted 减少目录层级；对 ESM 优先项目保持默认 isolation，防止幽灵依赖。

4. CI 缓存

   • 缓存 ~/.pnpm-store 和 node_modules/.pnpm，key 包含 pnpm-lock.yaml hash；避免缓存整个 node_modules。

5. 减少安装范围

   • CI 使用 pnpm install --frozen-lockfile --prefer-offline。
   • 本地开发 pnpm --filter <workspace> 只安装相关包。

6. 网络优化

   • 配置私有 registry 镜像、HTTP 代理、并发数 network-concurrency。
   • 审查依赖体积，替换重型 devDependency。

评分维度：

• 度量维度（30%）：能说出 lockfile、网络、store、硬链接等指标
• 优化手段（40%）：覆盖缓存、hoist、side-effects-cache、过滤安装
• 工程落地（30%）：能给出 CI cache key、registry、并发配置

常见错误：

• 直接缓存整个 node_modules，导致缓存体积大且容易失效
• 忽略 side-effects-cache 对 postinstall 重复执行的影响
• 盲目使用 hoisted 导致幽灵依赖

延伸追问：

• pnpm install --frozen-lockfile 在什么场景下会失败？
• 如何判断是网络下载慢还是本地链接慢？

参考资源：

• pnpm install options
• pnpm Store

口头回答版：

先度量 lockfile 解析、网络、store 写入和链接耗时。优化上开 side-effects-cache，合理设置 hoist，CI 里缓存 ~/.pnpm-store 和 node_modules/.pnpm，用 lockfile hash 做 key。安装时用 --frozen-lockfile --prefer-offline，本地用 --filter 减少范围，还可以换私有镜像。

---

FB-21-EN-B-072：如何通过 ESLint 配置与错误信息优化提升开发者体验

题型：工程化题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：ESLint、开发者体验 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 团队反馈 ESLint 报错晦涩、规则冲突多，部分成员倾向于 eslint-disable-next-line。请给出改善 ESLint 开发者体验的具体方案。

参考答案：

核心要点：提升 ESLint DX 需要升级配置体系、优化报错可读性、集成 IDE 自动修复，并通过渐进式推行和度量降低规则冲突与绕过行为。

详细解释：

1. 升级配置体系

   • 升级到 ESLint 9 flat config，集中为 eslint.config.js，按目录分层，避免 .eslintrc 级联混乱。

2. 报错可读性

   • 自定义规则使用 meta.messages 描述问题并给出修复示例。
   • 对复杂规则在文档站建立“为什么这条规则会报错”说明页，附带代码 diff。

3. 自动修复与 IDE 集成

   • 配置 --fix 在保存时运行；提供 VS Code settings.json 推荐，设置 eslint.useFlatConfig。
   • WebStorm 开启 ESLint 自动修复并指向仓库配置。

4. 渐进式推行

   • 新增规则先 warn 试运行两周，统计修复成本后转 error。
   • 对存量问题使用 eslint-interactive 批量修复。

5. 减少误报

   • 关闭与 Prettier 冲突的规则；对生成的代码、测试 fixtures 配置 ignores。

6. 度量

   • 统计 eslint-disable 注释数量、CI lint 失败率、平均修复时长。

评分维度：

• 配置现代化（30%）：能提到 flat config、分层、ignore
• 报错可读性（30%）：能说明自定义消息、文档、修复示例
• 推行与度量（40%）：能说出 warn->error、批量修复、指标

常见错误：

• 一次性开启大量新规则导致全仓库报错
• 只在 CLI 跑 ESLint，不在 IDE 实时提示
• 对生成的代码也跑规则，造成大量无效告警

延伸追问：

• 如何防止开发者滥用 eslint-disable？
• ESLint 9 flat config 与 .eslintrc 的解析差异有哪些？

参考资源：

• ESLint Flat Config
• eslint-interactive

口头回答版：

我会升级到 ESLint 9 flat config，把配置集中管理，按目录分层。规则报错信息要写清楚原因和修复示例，新增规则先 warn 两周再转 error。IDE 里配好保存自动修复，生成代码要 ignore。最后统计 eslint-disable 数量和 lint 失败率来看效果。

---

FB-21-SE-B-001：Jest 测试运行中的安全风险与敏感信息防护要点

题型：安全题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：Jest、文档 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 团队在 Jest 测试中大量使用了环境变量、第三方 API mock 和快照测试。请说明 Jest 测试环境中常见的安全风险及防护方法。

参考答案：

核心要点：Jest 测试安全需关注敏感信息泄露、任意代码执行、网络隔离、供应链和产物权限五个方面。

详细解释：

1. 敏感信息泄露

   • .env.test 中可能包含真实密钥；Jest 快照可能捕获 API 响应里的 token。
   • 应使用专门测试账号/假数据，snapshot 中添加 scrubber 脱敏。

2. 任意代码执行

   • 测试代码或 mock 服务器可能 eval/执行未经验证的数据。
   • 禁止在测试中使用 eval、new Function，mock 数据使用静态 fixture。

3. 网络隔离

   • 默认 Jest 可访问网络；CI 中配合 nock/msw 拦截，未 mock 的请求直接失败。

4. 依赖供应链

   • 审查 jest.config 中 transform 和 setupFiles 来源，锁定版本。

5. 产物权限

   • 测试报告、覆盖率文件上传到 artifact 时，避免包含 .env 或源码映射；设置 artifact 保留策略。

评分维度：

• 风险识别（40%）：能识别敏感信息、代码执行、网络、供应链风险
• 防护方案（40%）：能给出快照脱敏、网络隔离、 fixture 等具体措施
• 工程落地（20%）：能提到 CI 配置和 artifact 管理

常见错误：

• 在测试中使用生产数据库或真实密钥
• 快照包含随机 token 或用户隐私数据
• 认为测试代码不需要安全审查

延伸追问：

• 如何设计一个自动检测快照中敏感信息的工具？
• 在 Monorepo 中如何统一测试环境变量的管理？

参考资源：

• Jest Configuration
• MSW docs

口头回答版：

Jest 测试里最大的风险是敏感信息泄露，快照可能抓到 token，所以要用假数据和 scrubber。另外要禁止 eval，网络请求必须 mock，CI 里未 mock 的请求直接失败。测试报告上传 artifact 时别带 .env。

---

FB-21-SD-B-001：如何设计团队级 Prettier 与编辑器配置一致性方案

题型：系统设计题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：编辑器配置、Prettier 出现频率：高频 预计回答时长：3-5 分钟

题目描述： 团队同时使用 VS Code、WebStorm 等编辑器，经常出现保存后格式化结果不一致的情况。请设计一套可落地的配置同步方案。

参考答案：

核心要点：一致性方案应通过仓库级配置、EditorConfig、编辑器配置、提交门禁和 onboarding 文档形成闭环，让不同编辑器输出相同格式。

详细解释：

1. 仓库级配置

   • 根目录放置 .prettierrc.cjs 和 .prettierignore，纳入版本控制。
   • 在 package.json 中用 packageManager 固定 pnpm，确保 Prettier 版本一致。

2. EditorConfig 兜底

   • .editorconfig 统一换行符、缩进、编码，避免不同操作系统导致 diff。

3. 编辑器配置

   • VS Code 提交 .vscode/extensions.json 推荐 Prettier 插件，.vscode/settings.json 设置默认 formatter 和 formatOnSave。
   • WebStorm 通过 .idea/codeStyles/Project.xml 和 Prettier 插件指向仓库配置；README 写明导入步骤。

4. 提交门禁

   • Husky + lint-staged 在 pre-commit 对暂存区跑 prettier --write。
   • CI 跑 prettier --check 阻断不一致代码。

5. 教育与兜底

   • 新员工 onboarding 文档说明配置；提供一键 pnpm format 脚本。

评分维度：

• 配置统一（40%）：能说明 .prettierrc、EditorConfig、packageManager
• 编辑器适配（30%）：能覆盖 VS Code 和 WebStorm 配置
• 流程保障（30%）：能提到 pre-commit、CI、onboarding

常见错误：

• 依赖编辑器的默认格式化器而不固定 Prettier 版本
• 只配本地不配 CI，导致格式化规范被绕过
• 忽略换行符差异，Windows 与 macOS 成员反复产生 diff

延伸追问：

• 如果成员不愿安装推荐插件，你如何保证一致性？
• Prettier 3 的 resolveConfig 行为与之前有什么不同？

参考资源：

• Prettier Configuration File
• EditorConfig

口头回答版：

在仓库根放 .prettierrc 和 .editorconfig，固定 packageManager。VS Code 用 .vscode/settings.json 和 extensions.json 推荐插件，WebStorm 指向仓库配置。提交前用 lint-staged 跑 prettier，CI 跑 --check。 onboarding 里写清楚，大家就不容易格式不一致。

---

FB-21-CP-B-001：在 Docker 化前端工作流中如何落地 ESLint 并保证本地与 CI 一致性

题型：综合开放题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：Docker、ESLint 出现频率：高频 预计回答时长：3-5 分钟

题目描述： 团队计划使用 Docker 统一本地开发环境，同时希望 ESLint 在容器内外执行结果一致。请谈谈你的理解与实践经验。

参考答案：

核心要点：关键在于固定 Node/pnpm/ESLint 版本、统一配置挂载、处理缓存与行尾符，并让 CI 与本地 Dev Container 使用同一镜像。

详细解释：

1. 镜像一致性

   • Dockerfile 中固定 Node 版本、pnpm 版本，全局安装与项目一致的 ESLint 版本。
   • 使用 pnpm exec eslint 而非全局 eslint。

2. 配置挂载

   • 将 eslint.config.js、.eslintignore 和源码一起复制到镜像，避免容器内外配置不同。

3. 缓存策略

   • CI 中挂载或缓存 ESLint cache 目录（.eslintcache），但注意容器内路径一致。
   • 本地开发用 volume mount 实现实时 lint。

4. 权限与行尾符

   • Dockerfile 设置 WORKDIR 和 USER，统一 .gitattributes 为 LF，避免 CRLF 导致规则差异。

5. 集成方式

   • Dev Container 中配置 postCreateCommand 安装依赖。
   • CI 阶段将 lint 作为单独 job，与 build/test 并行。

6. 校验

   • 在 CI 中用同一镜像跑 pnpm lint，与本地 devcontainer run 结果对齐。

评分维度：

• 环境一致性（40%）：能说明 Node/pnpm/ESLint 版本固定、配置挂载
• 缓存与权限（30%）：能提到 .eslintcache、路径、CRLF
• 集成实践（30%）：能结合 Dev Container 和 CI job

常见错误：

• 容器内使用全局 ESLint 版本与项目 lock 不一致
• 把 node_modules 复制进镜像导致幽灵依赖或平台差异
• 忽略行尾符差异导致容器内外 lint 结果不同

延伸追问：

• 如何在不进入容器的情况下让本地 IDE 也能使用容器内的 ESLint？
• Dockerfile 中 COPY package.json 和 pnpm-lock.yaml 的顺序对缓存有什么影响？

参考资源：

• Dev Containers
• ESLint Command Line Interface

口头回答版：

用 Dockerfile 固定 Node 和 pnpm 版本，项目里用 pnpm exec eslint，不要全局装。把 eslint.config.js 一起打进镜像，统一 LF 换行。CI 里用同一镜像跑 lint，缓存 .eslintcache。Dev Container 可以在 postCreateCommand 里装依赖。

---

FB-21-CA-B-001：分析下面这段 barrel export 导致构建性能与产物体积问题的代码，并说明原因

题型：代码分析题 难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：21 开发者体验 标签：代码质量、构建性能 出现频率：中频 预计回答时长：3-5 分钟

题目描述： 某前端项目使用如下工具函数入口文件，发现生产构建耗时较长且产物体积超出预期。请分析原因并给出优化方向。

// src/utils/index.ts
export * from './date';
export * from './format';
export * from './validation';
export * from './chart'; // 依赖大型图表库

// src/pages/Home.tsx
import { formatDate } from '@/utils';

参考答案：

核心要点：barrel 文件通过 export * 把所有子模块重新导出，导致构建工具必须分析完整依赖图，并让重型库难以被 tree-shaking 排除。

详细解释：

1. 依赖图扩大

   • index.ts 把所有子模块重新导出，构建工具必须完整分析 index.ts 及其所有依赖。
   • 即使 Home.tsx 只使用 formatDate，构建工具仍需处理 chart 及其子依赖。

2. Tree-shaking 失效风险

   • chart 子模块若引入 echarts/d3 等大型库，且通过 export * 暴露，tree-shaking 信息不足时会被打包进产物。

3. 构建耗时增加

   • 分析更多模块、解析更多类型、生成更多 chunk；source map 体积增大。

4. 优化方向

   • 移除 star export，改为按需子路径导入：import { formatDate } from '@/utils/date'。
   • 使用 package.json#exports 声明子路径，支持 import { formatDate } from '@scope/utils/date'。
   • 对大型库使用动态导入 const chart = await import('./chart')。
   • 在构建配置中设置 sideEffects: false 辅助 tree-shaking。

评分维度：

• 问题定位（50%）：能指出 barrel export 导致 tree-shaking 失效和大型库被引入
• 优化方案（30%）：能给出子路径导入、exports 字段、动态导入
• 工程意识（20%）：能提到 sideEffects、source map、构建分析

常见错误：

• 认为 export * 不影响 tree-shaking
• 只关注代码运行时行为，忽略构建期依赖图
• 建议手动拆分所有文件到单独包但未说明 exports 配置

延伸追问：

• 如何验证优化后的产物确实不再包含 chart 库？
• package.json#sideEffects 对 export * 的结果有什么影响？

参考资源：

• Webpack Tree Shaking
• Package Entry Points

口头回答版：

这段代码用了 barrel export，把所有子模块都重新导出，导致构建工具要分析整个 utils，哪怕只用 formatDate。chart 里的大型库也会被带进来。优化办法是改成子路径导入，或者用 package.json exports，大型库动态引入，并配 sideEffects false。

---

FB-21-SS-A-001：请分享一次你推动 ESLint 规则升级与 CI 门禁落地的经历

题型：软技能题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：ESLint、CI/CD 出现频率：低频 预计回答时长：5-7 分钟

题目描述： 请用 STAR 法则描述一次你主导 ESLint 规则升级或 CI 门禁落地的经历，重点说明遇到的阻力和推动方法。

参考答案：

核心要点：成功的推行需要数据驱动、渐进 rollout、配套 IDE 与文档，并用量化指标证明收益。

详细解释：

1. 情境

   • 某 30 人前端团队使用老旧 ESLint 配置，规则松弛，PR 中频繁出现低级错误，CI 未阻断 lint 失败。

2. 任务

   • 在两个月内将 ESLint 升级到 9 并引入 flat config，实现 CI 强制门禁，同时不让业务线阻塞。

3. 行动

   • 调研：收集三个月 lint 错误分布，识别 Top 10 问题。
   • 制定路线图：先开 warn 收集两周数据；使用 eslint-interactive 批量修复 70% 自动修复项；对无法自动修复的规则启用临时豁免。
   • 沟通：在 tech sync 分享收益计算；与业务负责人约定分阶段合并窗口。
   • 工具：CI 增加 lint job，失败即阻断；IDE 配置保存自动修复；文档站新增规则说明。

4. 结果

   • lint 失败率从 15% 降到 2%，CI lint job 平均耗时 45s；开发者反馈报错更易懂。

5. 反思

   • 规则升级要配合 IDE 和文档，否则开发者会绕过；数据化收益更容易获得业务支持。

评分维度：

• 案例具体可信（40%）：有时间、团队规模、数据
• 角色与贡献清晰（30%）：能说明调研、沟通、工具落地
• 方法论总结（30%）：能提炼可复用的推行策略

常见错误：

• 只讲技术细节，不讲沟通和阻力
• 夸大个人贡献，忽略团队协作
• 没有量化结果，无法验证成效

延伸追问：

• 如果业务方以排期紧为由拒绝升级，你怎么回应？
• 你如何防止新规则上线后开发者大量添加 eslint-disable？

参考资源：

• ESLint Migrating to 9.0.0
• Conventional Comments

口头回答版：

之前团队 ESLint 很旧，CI 也不阻断。我先统计了三个月的错误分布，把升级分成 warn 试运行、自动修复、正式启用三步。用 eslint-interactive 修了大部分，和业务方约分阶段合并。结果 lint 失败率从 15% 降到 2%，CI 45 秒。关键是同步升级 IDE 配置和写文档，否则大家会绕过。

---

FB-21-CO-A-017：Cypress 与 Playwright 在端到端测试架构与 DX 上有哪些核心区别

题型：概念题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：Cypress、Playwright 出现频率：高频 预计回答时长：5-7 分钟

题目描述： 团队正在选型端到端测试框架，请对比 Cypress 与 Playwright 的架构差异，并说明在开发者体验上的优劣。

参考答案：

核心要点：Cypress 与被测应用同标签页运行，调试体验突出但跨域受限；Playwright 通过 CDP/BiDi 控制浏览器，支持多浏览器、多标签和更高效的并行。

详细解释：

1. 架构差异

   • Cypress：测试代码与被测应用在同一浏览器标签页运行，通过 Cypress Driver 注入；对跨域支持受限，需要 cy.origin 显式声明。
   • Playwright：基于 Chrome DevTools Protocol / WebDriver BiDi，测试进程与浏览器分离，支持多标签页、多浏览器、跨域更自然。

2. 运行速度

   • Playwright 默认多 worker 并行，测试隔离为全新 browser context。
   • Cypress 需要 Cypress Cloud 或第三方实现并行分片。

3. 调试体验

   • Cypress 提供 Time Travel、实时重载、DOM 快照。
   • Playwright 提供 Trace Viewer、Codegen、VS Code 插件。

4. 浏览器支持

   • Playwright 内置 Chromium/Firefox/WebKit。
   • Cypress 主要 Chromium/Firefox，WebKit 实验性。

5. 选型建议

   • 重视调试和单域稳定性选 Cypress；需要跨浏览器、多标签、CI 并行效率选 Playwright。

评分维度：

• 架构理解（40%）：能说明同一进程 vs 分离、跨域处理
• DX 对比（35%）：能对比调试、并行、浏览器支持
• 选型能力（25%）：能根据场景给出建议

常见错误：

• 认为 Cypress 和 Playwright 都是纯 Node 控制浏览器
• 忽略 Cypress 的跨域限制
• 只比较语法，不比较运行模型

延伸追问：

• 如果你的应用有多个子域登录流程，选哪个框架更合适？
• Playwright 的 browser context 隔离对测试数据管理有什么好处？

参考资源：

• Cypress How It Works
• Playwright Core Concepts

口头回答版：

Cypress 的测试代码跑在浏览器里，和页面同域，调试体验好但跨域受限。Playwright 用 CDP 控制浏览器，测试进程和浏览器分离，支持多标签、多浏览器、并行更快。重调试和单域选 Cypress，要跨浏览器和并行效率选 Playwright。

---

FB-21-SC-A-078：在 Vite 项目中需要支持 Babel 插件时，如何设计集成方案而不显著牺牲构建速度

题型：场景设计题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：Babel、Vite 出现频率：中频 预计回答时长：5-7 分钟

题目描述： 团队使用 Vite，但部分功能需要 Babel 插件处理（如 styled-components 的 displayName、lodash 按需编译）。请设计一套开发快、构建稳的集成方案。

参考答案：

核心要点：开发阶段用 esbuild/SWC 保证 HMR 速度；生产或特定文件再用 Babel，并通过范围控制和缓存避免性能退化。

详细解释：

1. 区分阶段

   • 开发时用 esbuild/SWC 保证 HMR 速度。
   • 生产构建或特定文件再用 Babel，避免全量 Babel 拖慢开发服务器。

2. 使用 @vitejs/plugin-react

   • 该插件内部在开发用 esbuild，生产可选 Babel；通过 babel: { plugins: [...] } 注入自定义 Babel 插件。

3. 精确范围

   • 使用 include/exclude 只在 src/components/**/*.tsx 应用 Babel；对 node_modules 跳过。

4. 独立 Babel 插件

   • vite-plugin-babel 可配置 filter 和 apply: 'build'，只在生产构建生效。

5. 缓存

   • 生产 Babel 转换结果通过 Vite 的构建缓存或文件系统缓存持久化；CI 中保留 .vite 缓存目录。

6. 度量

   • 对比开启 Babel 前后的 vite build 耗时，监控 HMR 时间是否退化。

评分维度：

• 阶段策略（35%）：能区分 dev 和 build 的转译策略
• 范围控制（30%）：能使用 include/exclude、apply: build
• 工具与缓存（20%）：能提到 plugin-react、vite-plugin-babel、缓存
• 度量意识（15%）：能给出构建耗时对比

常见错误：

• 开发阶段全量走 Babel 导致 HMR 变慢
• 对 node_modules 也应用自定义 Babel 插件
• 忽略缓存导致 CI 构建时间不稳定

延伸追问：

• 如果 Babel 插件必须处理 node_modules 中的某个包，如何配置？
• 如何验证 Babel 插件没有破坏 source map？

参考资源：

• Vite Plugin React
• vite-plugin-babel

口头回答版：

开发阶段尽量用 esbuild，生产或特定文件再用 Babel。Vite 的 plugin-react 支持 babel 配置，只对 src 下组件应用。可以用 apply: 'build' 让 Babel 只在生产生效，还要开缓存并监控 build 和 HMR 耗时。

---

FB-21-PE-A-075：组件库 Monorepo 中 Jest 测试越跑越慢，如何排查与优化

题型：性能优化题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：Jest、组件库 出现频率：中频 预计回答时长：5-7 分钟

题目描述： 某组件库 Monorepo 使用 Jest，随着包数量增加，本地 jest 和 CI 测试耗时明显增长。请给出排查思路和优化方案。

参考答案：

核心要点：先通过 verbose、heap 和单文件耗时定位瓶颈，再针对 transform、解析、测试代码和并行策略进行优化。

详细解释：

1. 度量

   • 使用 jest --verbose --runInBand 查看单文件耗时。
   • 使用 jest --logHeapUsage 检查内存。
   • CI 中输出每个 worker 的测试结果。

2. 瓶颈定位

   • transform 慢：大量 TS/JSX 文件未缓存；检查 transformIgnorePatterns 是否错误排除。
   • 模块解析慢：moduleNameMapper 过多或正则复杂；workspace 包之间交叉引用。
   • 测试代码问题：重复挂载、未清理的全局 mock、大对象深比较。

3. 优化手段

   • 替换 transform：ts-jest 换 @swc/jest 或 babel-jest；开启 isolatedModules。
   • 只跑 affected tests：jest --changedSince=origin/main 或 nx affected:test。
   • 并行与分片：CI 使用 --maxWorkers=2 避免容器 CPU 争抢；多 job shard 按 --shard=1/4 拆分。
   • 缓存：持久化 Jest cache，CI 中恢复。

4. 验证

   • 对比优化前后 P95 测试耗时，确保覆盖率不下降。

评分维度：

• 排查思路（30%）：能说出 verbose、heap、单文件耗时
• 优化手段（40%）：覆盖 transform、changedSince、shard、cache
• 工程落地（30%）：能结合 Monorepo 与 CI 配置

常见错误：

• 一上来就加 worker，不先定位 transform 瓶颈
• 忽略 transformIgnorePatterns 导致某些包未转译
• 测试文件之间共享全局状态导致不稳定

延伸追问：

• jest --changedSince 在跨包依赖变更时是否足够？
• 如何为组件库设计稳定的快照测试策略？

参考资源：

• Jest CLI Options
• Optimizing Jest

口头回答版：

先用 verbose 和 logHeapUsage 看哪个文件慢。常见瓶颈是 transform、模块解析和测试代码。把 ts-jest 换成 swc/jest，用 --changedSince 只跑受影响测试，CI 里用 shard 和合理 worker 数，还要缓存 Jest cache。

---

FB-21-EN-A-079：在 pnpm Monorepo 中落地 Vite 需要解决哪些依赖链接与别名配置问题

题型：工程化题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：pnpm、Vite 出现频率：高频 预计回答时长：5-7 分钟

题目描述： 团队使用 pnpm workspace 管理多个应用和组件库，现在要在其中落地 Vite。请说明常见的依赖链接、peer dependency 和路径别名问题及解决方案。

参考答案：

核心要点：关键是正确使用 workspace 协议、配置 optimizeDeps、处理 peerDeps、同步 tsconfig 别名，并保证 HMR 跨包生效。

详细解释：

1. workspace 协议

   • 内部包使用 "workspace:*" 引用，pnpm 自动链接；Vite 预构建需识别这些包。
   • 在 vite.config.ts 配置 optimizeDeps.include 包含 workspace 包，避免首次加载慢。

2. peer dependency

   • 组件库将 React/Vue 声明为 peerDeps，应用负责安装。
   • pnpm 严格依赖结构下，未声明 peer 会告警；使用 .pnpmfile.cjs 或 packageExtensions 修复上游 peer 声明。

3. public hoist

   • Vite 插件有时需要被 hoist 到 root，配置 .npmrc 的 public-hoist-pattern[]=*vite*，否则插件版本解析可能失败。

4. 路径别名

   • Monorepo 中 tsconfig paths 与 Vite resolve.alias 同步；使用 vite-tsconfig-paths 插件自动读取 tsconfig，避免重复配置。

5. HMR 跨包

   • 修改 workspace 组件库源码后，Vite 应通过 server.fs.allow 或 watch 包含 workspace 目录，确保 HMR 生效。

6. 锁定与缓存

   • CI 使用 pnpm install --frozen-lockfile，缓存 ~/.pnpm-store；Vite 缓存 .vite 目录。

评分维度：

• workspace 链接（30%）：能说明 workspace:*、optimizeDeps.include
• peer dependency（25%）：能解释 peerDeps 和 pnpm 严格依赖
• 别名与 HMR（25%）：能提到 tsconfig paths、vite-tsconfig-paths、watch
• 缓存（20%）：能说明 pnpm store 和 Vite 缓存

常见错误：

• 用相对路径 ../../packages/ui 引用内部包
• 未将 Vite 插件 public hoist 导致插件找不到
• tsconfig paths 和 Vite alias 不同步导致类型和运行不一致

延伸追问：

• 当组件库有 peerDeps 时，Vite 预构建会不会把 peer 打包进去？
• 如何解决 workspace 包修改后 HMR 不生效的问题？

参考资源：

• pnpm Workspaces
• vite-tsconfig-paths

口头回答版：

内部包用 workspace:*，Vite 里配 optimizeDeps.include。peerDeps 要声明好，必要时用 pnpmfile 修。路径别名用 vite-tsconfig-paths 自动同步 tsconfig。Vite 插件可能要 public hoist。HMR 要 watch workspace 目录，CI 缓存 pnpm store 和 .vite。

---

FB-21-SE-A-001：使用 Playwright 进行端到端测试时，如何防范测试脚本中的安全与数据风险

题型：安全题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：团队协同、Playwright 出现频率：中频 预计回答时长：5-7 分钟

题目描述： 团队用 Playwright 覆盖核心业务流程，测试中涉及登录态、用户数据和第三方服务。请说明测试中应关注的安全与数据风险及防护措施。

参考答案：

核心要点：应通过 context 隔离、凭据管理、第三方服务拦截、脚本安全和报告脱敏来降低风险。

详细解释：

1. 测试数据隔离

   • 每个测试使用新的 browser.newContext()，避免 cookie/localStorage 污染。
   • 使用 storageState 复用认证状态时确保状态文件不提交到仓库。

2. 凭据管理

   • 将测试账号密码放在 CI secrets 或 .env.test.local，不在脚本中硬编码。
   • 使用专用测试租户，避免访问生产数据。

3. 第三方服务

   • 通过 page.route 拦截外部 API，返回 fixture 数据。
   • 对必须访问的真实服务使用只读测试账号。

4. 脚本安全

   • 不在测试代码中使用 eval 或动态字符串执行。
   • 审查 test.extend 中自定义 fixtures 的权限。

5. 报告与 trace

   • Playwright trace 可能包含输入的敏感信息，上传 CI artifact 前配置 trace: 'retain-on-failure' 并设置 artifact 保留期。
   • 对公共仓库关闭 trace 自动上传。

评分维度：

• 数据隔离（30%）：能说明 context 隔离、storageState、测试租户
• 凭据与第三方（30%）：能提到 secrets、route 拦截、fixture
• 脚本与报告安全（25%）：能指出 eval 风险、trace 脱敏
• 工程落地（15%）：能结合 CI 配置

常见错误：

• 多个测试共享同一个登录态 context
• 在测试脚本里写死真实用户名密码
• 对第三方 API 不做拦截，测试不稳定且可能污染数据

延伸追问：

• 如何为不同角色设计可复用的认证 fixture？
• Playwright trace 文件过大时如何控制存储成本？

参考资源：

• Playwright Authentication
• Playwright Network

口头回答版：

每个测试用新的 browser context，凭据放 CI secrets 或 .env.test.local，别写死在脚本里。第三方 API 用 page.route 拦截返回 fixture。trace 可能带敏感信息，失败才保留，artifact 要设保留期。

---

FB-21-SD-A-001：如何为内部组件库设计可观测性方案，以度量组件使用与性能

题型：系统设计题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：可观测性、组件库 出现频率：低频 预计回答时长：5-7 分钟

题目描述： 团队维护一套内部 React 组件库，希望了解哪些组件被使用、哪些性能差、哪些常报错。请设计一套可观测性方案。

参考答案：

核心要点：应采集真实代码使用、运行时性能、错误率和产物体积，并建立组件健康度指标驱动治理。

详细解释：

1. 使用统计

   • 在构建工具中注入 Babel 插件或 webpack loader，扫描 import { Button } from '@scope/ui' 用法。
   • 生成组件使用热力图，结合 source map 定位业务线。

2. 运行时性能

   • 在关键组件挂载/更新时使用 React.Profiler 或 Performance API 采集渲染耗时。
   • 通过 Error Boundary 捕获组件级错误并上报。

3. 构建产物

   • 对每个组件包生成 bundle size 报告，使用 bundlesize 或 size-limit 在 PR 中告警。
   • 趋势图展示体积变化。

4. 文档与反馈

   • 在 Storybook 中添加 Usage addon 展示使用示例和热力。
   • 提供一键提 issue 链接，收集开发者反馈。

5. 治理

   • 定义组件健康度指标（使用率、渲染耗时 P95、错误率、体积），定期下线低价值组件。

评分维度：

• 采集维度（35%）：能覆盖使用统计、性能、错误、体积
• 技术方案（35%）：能给出 Babel 插件、Profiler、Error Boundary 等具体手段
• 治理闭环（30%）：能说明健康度指标、下线和反馈机制

常见错误：

• 只在文档里统计点击量，不能反映真实代码使用
• 运行时采集过于侵入，影响组件性能
• 只关注错误率，不关注使用率和体积

延伸追问：

• 如何在不暴露业务代码的前提下采集组件使用数据？
• 组件库版本升级后，如何追踪哪些业务线还在用旧 API？

参考资源：

• React Profiler API
• size-limit

口头回答版：

我会用 Babel 插件扫描组件引用做使用热力图，React Profiler 采集渲染耗时，Error Boundary 抓报错，再用 size-limit 监控体积。然后定义组件健康度，把使用率、性能、错误率、体积综合起来，定期下线没人用的组件。

---

FB-21-CP-A-076：如何平衡开发者体验的灵活性与环境一致性

题型：综合开放题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：开发者体验、环境一致性 出现频率：高频 预计回答时长：5-7 分钟

题目描述： 团队开发者希望保留本地自由选择编辑器、插件和 Node 版本，但平台工程要求环境一致以减少“我本地能跑”的问题。请结合一次实践谈谈如何平衡。

参考答案：

核心要点：明确“必须一致”与“可灵活”的边界，用工具保证底线一致，同时通过可选 Dev Container 和反馈机制保留灵活性。

详细解释：

1. 分层一致

   • 必须一致：Node 版本、包管理器、依赖版本、代码规范。
   • 可灵活：编辑器主题、插件选择、本地调试端口。

2. 工具落地

   • 用 .nvmrc + engines + corepack packageManager 锁定 Node/pnpm。
   • 用 Dev Container 提供可选的统一环境，但不强制。
   • 用 .editorconfig 和 Prettier 保证文件级一致。

3. 渐进推行

   • 先在 CI 上强制执行版本和规范，本地推荐 Dev Container。
   • 对不接受容器化的成员提供裸机启动脚本和文档。

4. 反馈机制

   • 每月收集 DX 问卷，统计因环境不一致导致的 CI 失败数。
   • 用数据证明一致性带来的收益。

5. 取舍案例

   • 某团队引入 Dev Container 后，新成员 onboarding 从 2 天降到 2 小时；对高级开发者保留裸机脚本，满足灵活性。

评分维度：

• 边界划分（35%）：能区分必须一致和可灵活的部分
• 工具与实践（35%）：能提到 nvmrc、corepack、Dev Container、Prettier
• 推行与度量（30%）：能说明渐进策略和 DX 问卷

常见错误：

• 一刀切强制所有开发者使用 Dev Container
• 只强调环境一致，忽视开发者习惯和效率
• 缺少度量，无法证明收益

延伸追问：

• 当部分成员拒绝 Dev Container 时，你如何降低裸机环境的不一致性？
• 你如何衡量环境一致性对 CI 失败率的实际影响？

参考资源：

• corepack
• Dev Containers Specification

口头回答版：

我会把必须一致的边界定清楚：Node、包管理器、依赖、代码规范。其他像编辑器可以灵活。用 nvmrc、corepack、Prettier 保证底线，Dev Container 作为可选方案。先在 CI 强制执行，再慢慢推广。每月收集反馈，用 onboarding 时间和 CI 失败率证明收益。

---

FB-21-CA-A-001：分析一段 Turborepo pipeline 配置，指出缓存命中失败的原因

题型：代码分析题 难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：21 开发者体验 标签：Turborepo、环境一致性 出现频率：高频 预计回答时长：5-7 分钟

题目描述： 某团队使用 Turborepo 后，发现 turbo run build 经常无法命中本地缓存。以下是 turbo.json 片段，请分析原因并修正。

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["lint"],
      "outputs": [".next/**"]
    },
    "lint": {}
  }
}

业务代码中使用了 process.env.NEXT_PUBLIC_API_URL。

参考答案：

核心要点：缓存命中失败通常由依赖关系错误、环境变量未声明、outputs 不完整导致，需要逐条修正。

详细解释：

1. dependsOn 错误

   • build 依赖 lint 不必要，lint 失败不应阻塞产物生成；应改为 dependsOn: ["^build"] 表示等依赖包 build 完成。

2. 环境变量未声明

   • Turborepo 默认不将环境变量纳入缓存键，若代码读取 NEXT_PUBLIC_API_URL，必须在 build 任务中声明 env: ["NEXT_PUBLIC_API_URL"]，否则不同环境会误命中缓存。

3. outputs 不完整

   • Next.js 还会生成 !**/*.map 等，建议补充 dist/** 或 .next/** 并用 !**/*.map 排除 sourcemap；同时声明任务 inputs 控制缓存粒度。

4. 修正示例

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "env": ["NEXT_PUBLIC_API_URL"],
      "outputs": [".next/**", "!.next/cache/**"],
      "inputs": ["src/**", "package.json", "next.config.*"]
    },
    "lint": {}
  }
}

评分维度：

• dependsOn 理解（30%）：能指出不应依赖 lint
• env 与缓存键（35%）：能说明 env 声明对缓存的影响
• outputs/inputs（20%）：能补充输出和输入声明
• 给出修正（15%）：能写出修正配置

常见错误：

• 认为 Turborepo 会自动把 process.env 所有变量加入缓存键
• 把 lint 作为 build 的依赖，导致缓存链过长
• outputs 只写 .next/** 导致缓存包含不应缓存的目录

延伸追问：

• 如果 NEXT_PUBLIC_API_URL 在每个环境都不同，如何避免频繁缓存失效？
• Turborepo 的 globalEnv 和任务级 env 有什么区别？

参考资源：

• Turborepo Caching
• Turborepo Pipeline

口头回答版：

build 不应该 dependsOn lint，缓存链太长。代码里用了 NEXT_PUBLIC_API_URL，必须在 turbo.json 的 env 里声明，否则换环境会误命中缓存。outputs 也要完整，最好加 inputs 控制粒度。改完后 dependsOn 用 ^build，env 和 outputs 声明清楚。

---

FB-21-EN-P-085：如何在组件库文档站点中落地 Design Token 以实现代码与设计同步

题型：工程化题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：文档、Design Token 出现频率：高频 预计回答时长：7-10 分钟

题目描述： 团队希望组件库文档站点能实时展示 Design Token，并保证设计变更后代码产物同步更新。请给出工程化方案。

参考答案：

核心要点：通过独立 Token 包、转换管线、文档站点插件和 CI 同步机制，实现设计源与代码产物的一致性。

详细解释：

1. Token 源

   • 使用 W3C Design Token Community Group 格式或 Style Dictionary 的 JSON，放在独立 package @scope/tokens，版本与组件库对齐。

2. 转换管线

   • 使用 Style Dictionary 或 token-transformer 将 token 转换为 CSS 自定义属性、SCSS 变量、JS/TS 对象。
   • 在组件库构建时作为依赖引入。

3. 文档站点集成

   • VitePress/Docusaurus 中编写 remark 插件或 Vue/React 组件，读取 token JSON 并渲染色板、字体、间距表格。
   • 示例代码引用 CSS var。

4. 同步机制

   • 设计工具（Figma Token Studio）通过 Git sync 提交 token JSON。
   • CI 中运行 tokens:build，若产物变化则自动提交 PR 或触发组件库发布。

5. 校验

   • 写测试断言 CSS 变量与 token JSON 一致。
   • PR 中展示 token diff，防止设计变更静默上线。

评分维度：

• Token 管理（30%）：能说明 W3C/Style Dictionary、独立包
• 文档集成（30%）：能给出 remark 插件/组件渲染 token
• 同步与校验（40%）：能说明设计工具同步、CI 构建、diff 校验

常见错误：

• 把 Design Token 硬编码在组件样式里，不单独管理
• 文档站点手动维护色板，和设计源脱节
• 缺少自动化校验，设计更新后代码未同步

延伸追问：

• 当设计师频繁调整 token 时，如何避免组件库版本号爆炸？
• 如何支持暗黑模式或多主题的 token 切换？

参考资源：

• Style Dictionary
• W3C Design Tokens

口头回答版：

Token 用 JSON 管理，独立成一个包，用 Style Dictionary 转成 CSS 变量、JS 对象。文档站点里写组件读取 token 渲染色板。设计和代码同步可以用 Figma Token Studio 提交到 Git，CI 自动构建并校验 diff。

---

FB-21-SE-P-001：Monorepo 使用 Turborepo 远程缓存时的安全风险与访问控制

题型：安全题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：Turborepo、组件库 出现频率：低频 预计回答时长：7-10 分钟

题目描述： 团队计划启用 Turborepo Remote Cache 加速 CI。请说明远程缓存可能带来的安全风险及访问控制方案。

参考答案：

核心要点：远程缓存需防范缓存污染、敏感信息泄露，并通过签名、权限分级、审计和回退策略保证安全。

详细解释：

1. 缓存污染

   • 攻击者若拥有写权限，可上传带恶意产物的缓存。
   • 应启用缓存签名并校验签名；CI 只暴露只读 token 给 PR，写 token 只在 main 分支合并后使用。

2. 敏感信息泄露

   • 构建产物中可能包含 .env 或 source map。
   • 通过 .gitignore 和 turbo outputs 排除敏感文件；对远程存储启用服务端加密。

3. 访问控制

   • 使用 Vercel Remote Cache 时按 team/role 分配 token。
   • 自建 S3 时使用 IAM Role 与 bucket policy，限制 IP 和 CI runner。

4. 审计与轮换

   • 记录缓存上传/下载日志；定期轮换 TURBO_TOKEN。
   • 对离职成员立即撤销 token。

5. 回退策略

   • 配置 --remote-only 仅在缓存可用时使用，同时保留本地回退。
   • 对安全攸关构建禁用远程缓存。

评分维度：

• 风险识别（35%）：能指出缓存污染、敏感信息泄露
• 访问控制（35%）：能说明 token 权限、签名、IAM
• 审计与回退（30%）：能提到日志、轮换、回退策略

常见错误：

• 把写 token 放在所有分支和 PR 中
• 远程缓存中包含 source map 或 .env
• 忽略缓存签名导致信任任意缓存

延伸追问：

• 如何验证下载的缓存产物确实来自可信 CI 构建？
• 自建 S3 远程缓存时，怎样防止缓存被外部扫描？

参考资源：

• Turborepo Remote Caching
• Turborepo Scoped Tokens

口头回答版：

远程缓存最大的风险是污染和泄露。要给缓存签名，CI 里 PR 用只读 token，main 才用写 token。outputs 里不能包含 .env 和 sourcemap，存储要加密。还要记日志、定期换 token，必要时禁用远程缓存。

---

FB-21-SD-P-080：如何设计可在 Storybook 文档中实时格式化示例代码的 Prettier Playground 组件

题型：系统设计题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：Prettier、Storybook 出现频率：中频 预计回答时长：7-10 分钟

题目描述： 团队希望在 Storybook 的组件文档里嵌入一个交互式代码格式化器，让开发者可以粘贴代码并看到 Prettier 格式化结果。请设计该组件及其工程实现。

参考答案：

核心要点：使用 Prettier standalone 在浏览器端格式化，并通过 Web Worker、配置同步和懒加载保证体验与性能。

详细解释：

1. 组件架构

   • 在 Storybook 中写一个 React/Vue 组件 PrettierPlayground，包含代码编辑器（CodeMirror/Monaco）、配置面板和输出区。

2. Prettier 运行时

   • 使用 prettier/standalone + 所需 parser 插件，避免加载完整 Node 版。
   • 在 Web Worker 中运行格式化，避免阻塞 UI。

3. 配置同步

   • 读取仓库 .prettierrc，在配置面板展示可覆盖项；默认使用仓库配置。

4. 安全

   • 对用户输入代码只做格式化，不执行。
   • 使用 iframe 或 CSP 限制；避免加载未知 parser 插件。

5. 集成

   • 作为 Storybook addon 或 MDX 组件；构建时将示例代码和 playground 一起打包。
   • CI 校验示例代码本身能被 Prettier 通过。

6. 性能

   • 懒加载 parser 和 Prettier；对长代码做 debounce；提供 copy 和 diff 视图。

评分维度：

• 组件设计（30%）：能说明编辑器、配置、输出分区
• Prettier 运行时（30%）：能提到 standalone、Web Worker、parser 插件
• 工程集成（25%）：能说明 Storybook addon/MDX、仓库配置同步
• 安全与性能（15%）：能提到不执行代码、懒加载、debounce

常见错误：

• 在浏览器端直接引入 Node 版 Prettier
• 忽略 parser 插件按需加载导致包体积过大
• 执行用户输入代码造成 XSS

延伸追问：

• 如何让 Playground 中的配置与团队 .prettierrc 实时同步？
• 如果示例代码包含未支持的语法，如何友好报错？

参考资源：

• Prettier Browser
• Storybook Addons

口头回答版：

用 prettier/standalone 加 parser 插件，在 Web Worker 里跑格式化。Storybook 里做一个 Playground 组件，读仓库的 .prettierrc 做默认配置。用户输入只格式化不执行，长代码 debounce，parser 懒加载。

---

FB-21-CP-P-082：如何结合 Babel 代码转换与 Playwright 测试实现自动化兼容性验证

题型：综合开放题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：Babel、Playwright 出现频率：低频 预计回答时长：7-10 分钟

题目描述： 团队希望验证 Babel 转译后的代码在真实浏览器中的行为，并自动检测兼容性问题。请结合 Babel 与 Playwright 设计一套方案。

参考答案：

核心要点：通过多 targets 产物矩阵、Playwright 多浏览器覆盖和 CI 自动化流程，验证转译产物在真实环境中的行为。

详细解释：

1. Babel 转译矩阵

   • 配置多组 Babel preset（如 targets: modern/es5）生成不同产物，分别部署为 /modern 和 /legacy。

2. Playwright 多浏览器覆盖

   • 使用 Playwright 的 project 配置在 Chromium/Firefox/WebKit 上运行同一套测试。
   • 对 legacy 包使用指定 UA 或 old browser 镜像。

3. 自动化流程

   • CI 中先跑 Babel 构建生成产物，再启动静态服务器，Playwright 连接该服务器执行 E2E。
   • 失败时保留 trace 和产物 diff。

4. 兼容性断言

   • 通过 Babel 插件在代码中注入特征标记（如 __BUILD_TARGET__），Playwright 测试读取 DOM 属性验证实际加载的是哪个产物。

5. 回归防控

   • 将每次构建产物哈希与测试结果关联。
   • 对转译后的代码运行 eslint-plugin-compat 静态检查作为前置。

评分维度：

• 转译矩阵（25%）：能说明多 targets 产物生成
• Playwright 覆盖（25%）：能说明多浏览器、多版本
• 自动化集成（25%）：能给出 CI 流程和产物验证
• 回归防控（25%）：能提到 feature flag、compat lint

常见错误：

• 只在现代浏览器跑测试，忽略 legacy 产物
• 转译产物未版本化，无法回溯问题
• Playwright 直接测试源码而非构建产物

延伸追问：

• 如何验证 Babel 的 @babel/preset-env 是否引入了不必要的 polyfill？
• 如果测试发现某个旧浏览器报错，如何定位是哪个 Babel 插件导致的？

参考资源：

• Playwright Projects
• Babel preset-env

口头回答版：

用 Babel 按不同 targets 生成 modern 和 legacy 产物，Playwright 在多个浏览器上跑同一套测试连到这些产物。CI 里先构建再测，保留 trace。可以在代码里注入 build target 标记，测试里验证实际加载的产物。

---

FB-21-CA-P-001：分析一段 GitHub Actions 工作流，找出影响 CI 反馈时间和一致性的问题

题型：代码分析题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：CI/CD、Docker 出现频率：高频 预计回答时长：7-10 分钟

题目描述： 以下是某前端项目的 GitHub Actions 配置，请分析其中影响 CI 反馈时间和环境一致性的问题，并给出优化建议。

name: CI
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
      - run: npm run lint
      - run: npm run test
      - run: npm run build

参考答案：

核心要点：该配置存在缓存缺失、包管理器不一致、runner 标签漂移、串行执行和 Node 版本模糊等问题。

详细解释：

1. 无依赖缓存

   • 每次 npm install 全量下载；应使用 actions/setup-node 的 cache: 'npm' 或 actions/cache 缓存 ~/.npm。

2. 包管理器不一致

   • 项目若使用 pnpm 但 CI 用 npm，lock 文件可能不生效；应使用 pnpm/action-setup 并 cache: 'pnpm'。

3. 运行时标签漂移

   • ubuntu-latest 会随 GitHub 升级改变系统库；应固定 ubuntu-22.04。

4. 串行执行

   • lint/test/build 串行，反馈慢；拆分为并行 job，如 lint、test、build 同时跑。

5. Node 版本模糊

   • node-version: '18' 可能安装 18.x 最新补丁，建议用 .nvmrc 并 node-version-file: '.nvmrc'。

6. 无产物复用

   • build 产物可在 E2E 等下游复用，使用 actions/upload-artifact 和 download-artifact。

评分维度：

• 缓存与安装（35%）：能指出 npm/pnpm 缓存、lock 一致性
• 一致性与并行（35%）：能说明固定 runner、Node 版本、并行 job
• 产物复用（20%）：能提到 artifact
• 修正示例（10%）：能给出优化后的配置片段

常见错误：

• 只指出缺少缓存，没发现包管理器不一致
• 建议把所有步骤合并成一个 job 以“简化”
• 忽略 runner 标签漂移

延伸追问：

• 如果测试 job 依赖 build 产物，如何设计 artifact 传递？
• 并行 job 增多后，如何控制 GitHub Actions 的并发成本？

参考资源：

• GitHub Actions Caching
• pnpm GitHub Action

口头回答版：

主要问题：没缓存、包管理器用 npm 而项目用 pnpm、ubuntu-latest 会漂移、Node 版本太粗、步骤串行。优化：用 pnpm action-setup 加缓存，固定 ubuntu-22.04 和 .nvmrc，lint/test/build 并行，产物用 artifact 传递。

---

FB-21-CD-P-001：请手写一个 pre-commit 钩子脚本，对变更文件运行受影响的最小测试集

题型：手写代码题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：Git、测试策略 出现频率：低频 预计回答时长：7-10 分钟

题目描述： 请在面试中手写一个 pre-commit 钩子（bash 或 Node），实现：仅对暂存区中变更的 JS/TS 文件，使用 Jest 的 --findRelatedTests 跑相关测试；若测试失败则阻止提交。

参考答案：

核心要点：钩子应只读取暂存区文件、过滤 JS/TS、调用 --findRelatedTests、失败时以非零退出码阻断提交。

详细解释：

Bash 示例：

#!/bin/bash
set -euo pipefail

STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACMR | grep -E '\.(js|jsx|ts|tsx)$' || true)

if [ -z "$STAGED_FILES" ]; then
  echo "No JS/TS files staged, skipping tests."
  exit 0
fi

echo "Running related tests for:"
echo "$STAGED_FILES"

FILES_SINGLE_LINE=$(echo "$STAGED_FILES" | tr '\n' ' ')
pnpm jest --findRelatedTests $FILES_SINGLE_LINE --passWithNoTests

Node 示例：

#!/usr/bin/env node
const { execSync } = require('node:child_process');
const files = execSync('git diff --cached --name-only --diff-filter=ACMR')
  .toString()
  .split('\n')
  .filter(f => /\.(js|jsx|ts|tsx)$/.test(f));

if (!files.length) {
  console.log('No JS/TS files staged, skipping tests.');
  process.exit(0);
}

execSync(`pnpm jest --findRelatedTests ${files.join(' ')} --passWithNoTests`, {
  stdio: 'inherit',
});

要点：只取 staged 文件、过滤类型、失败时 exit code 非零、Husky 注册。

评分维度：

• 脚本正确性（40%）：能正确获取暂存区文件并调用 jest --findRelatedTests
• 边界处理（30%）：能处理无匹配文件、空格路径、exit code
• 可维护性（20%）：有清晰输出和错误处理
• 性能意识（10%）：只跑相关测试而非全量

常见错误：

• 跑全量测试导致提交极慢
• 对 deleted 文件也跑测试
• 不处理路径中的空格导致命令解析错误

延伸追问：

• 如何确保新增的测试文件（未 import）也能被跑？
• 如果测试依赖未暂存的文件，--findRelatedTests 会有什么表现？

参考资源：

• Jest --findRelatedTests
• Git diff --cached

口头回答版：

用 git diff --cached 拿到暂存文件，过滤 js/ts，然后调 pnpm jest --findRelatedTests。没有匹配文件就跳过，失败时返回非零。Node 版用 execSync，把文件用空格拼起来。

---

FB-21-FS-P-001：Prettier 的 AST 打印流程是什么？如何为文档站点定制代码格式化插件

题型：框架原理题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：Prettier、文档 出现频率：中频 预计回答时长：7-10 分钟

题目描述： 请解释 Prettier 从源代码到格式化输出的核心流程，并说明如何为文档站点中的自定义 DSL 编写一个 Prettier 插件。

参考答案：

核心要点：Prettier 通过 parse -> doc -> print -> output 四步输出代码；定制插件需实现 parser 和 printer。

详细解释：

1. 核心流程

   • 解析：调用 parser（如 babel、typescript）生成 AST。
   • 转换：Prettier 将 AST 转换为中间表示 doc（由 builders 如 concat, group, indent, ifBreak 组成）。
   • 打印：printer 遍历 AST 节点，调用 print 生成 doc；doc-printer 根据 printWidth/tabWidth 将 doc 渲染为字符串。
   • 输出：处理 cursor、range、endOfLine 等后输出代码。

2. 插件结构

   • 实现 parsers（提供 parse 函数和 astFormat）、printers（提供 print 函数处理对应 astFormat）、options 和 defaultOptions。

3. 文档站点 DSL

   • 假设 DSL 为 <Example lang="ts" code="..."/>，插件解析后只格式化 code 属性内的代码，保留外层标签结构。
   • 使用 embeddedLanguageFormatting 控制。

4. 调试

   • 使用 prettier --debug-print-doc 查看 doc。
   • 用 prettier --plugin 加载本地插件。

评分维度：

• AST 与 doc 流程（40%）：能说明 parse、doc、print、output
• 插件结构（30%）：能说明 parsers/printers/options
• DSL 定制（20%）：能给出具体处理思路
• 调试能力（10%）：能提到 debug-print-doc

常见错误：

• 认为 Prettier 直接基于字符串正则格式化
• 把 parser 和 printer 职责混淆
• 忽略 doc 中的 group/indent 对换行的影响

延伸追问：

• Prettier 如何处理同一节点存在多种合法格式的情况？
• 写插件时如何保持与内置 printer 的嵌套格式一致？

参考资源：

• Prettier Plugin API
• Prettier API

口头回答版：

Prettier 先用 parser 生成 AST，再转成 doc 中间表示，最后 printer 渲染成字符串。定制插件要实现 parsers 和 printers，对文档站点的 DSL 可以只格式化 code 属性里的代码，保留外层标签。调试可以用 --debug-print-doc。

---

FB-21-SS-P-084：请分享一次你主导的前端工程化或 CI/CD 改进项目

题型：软技能题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：前端工程化、GitHub Actions 出现频率：中频 预计回答时长：7-10 分钟

题目描述： 请用具体案例说明一次你主导的前端工程化、CI/CD 或开发者体验改进项目，重点讲如何推动团队接受并度量收益。

参考答案：

核心要点：案例应包含清晰的数据基线、试点策略、统一模板和可量化的收益。

详细解释：

1. 情境

   • 某 50 人前端团队，10 个仓库各自维护 webpack 配置，构建时间平均 8 分钟，新人上手需 3 天。

2. 任务

   • 用 3 个月推进构建工具统一为 Vite，并建立统一 CI 模板，目标构建时间降到 2 分钟、onboarding 降到半天。

3. 行动

   • 建立度量：在 CI 中记录每个项目 build/install 耗时，绘制趋势图。
   • 试点：选 2 个核心项目迁移，沉淀 vite-config 共享包和迁移手册。
   • 标准化：推出 frontend-ci-template GitHub Actions reusable workflow，统一 pnpm、缓存、artifact、Turborepo。
   • 推广：技术分享 + 迁移窗口期；对阻塞问题成立专项小组。
   • 治理：将构建耗时纳入团队 OKR；设置 CI 失败率和构建时间告警。

4. 结果

   • 构建 P95 从 8 分钟降到 1.8 分钟；onboarding 时间降到 0.5 天；CI 失败率下降 35%。

5. 反思

   • 统一工具必须提供可复用模板，不能只推规范；度量数据是说服业务的关键。

评分维度：

• 案例具体可信（40%）：有规模、时间、指标
• 推动过程（30%）：能说明试点、模板、推广
• 收益度量（30%）：能给出前后数据和 OKR

常见错误：

• 只说技术选型，不讲团队协作
• 收益没有量化
• 忽略迁移阻力和沟通成本

延伸追问：

• 在迁移过程中，如何处理遗留项目的兼容性？
• 如果某个团队坚持使用原有工具，你如何决策？

参考资源：

• DORA Metrics
• GitHub Reusable Workflows

口头回答版：

之前团队十个仓库各配 webpack，构建平均 8 分钟。我选了两个项目试点 Vite，沉淀了共享配置和迁移手册，再推出统一的 GitHub Actions 模板。推广时做技术分享、开专项小组。结果构建降到 1.8 分钟，新人上手半天，CI 失败率降 35%。

---

FB-21-CO-P-001：Webpack 构建过程的可观测性指标有哪些？如何通过 stats 与 telemetry 实现

题型：概念题 难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：21 开发者体验 标签：可观测性、Webpack 出现频率：高频 预计回答时长：7-10 分钟

题目描述： 团队使用 Webpack 构建大型应用，希望建立构建过程的可观测性。请说明可采集的关键指标和具体实现方式。

参考答案：

核心要点：通过 Webpack Stats、compiler hooks 和自定义插件采集阶段耗时、loader/plugin 耗时、产物体积和缓存命中率，并接入 metrics 服务。

详细解释：

1. 关键指标

   • 阶段耗时：init、make、seal、emit；通过 compilation.hooks 打点。
   • loader/plugin 耗时：speed-measure-webpack-plugin 或自定义 NormalModuleLoader hook 计时。
   • 产物体积：按 chunk、entry、模块拆分；使用 webpack-bundle-analyzer。
   • 模块数量与依赖深度：stats.modules 中分析。
   • 缓存命中率：cache 的 hit/miss 事件（webpack 5 persistent cache）。

2. 实现方式

   • 使用 webpack.Stats 的 toJson({ all: false, timings: true, modules: true }) 输出结构化数据。
   • 自定义插件监听 compiler.hooks.done 和 compilation.hooks.buildModule，将指标 push 到 Prometheus/OTel。
   • CI 中输出 stats.json，用脚本解析后写入 metrics 服务；PR 中展示体积变化。

3. 告警

   • 模块数突增、某个 loader 耗时翻倍、产物体积超过基线 10% 时告警。

评分维度：

• 指标覆盖（35%）：能覆盖阶段、loader、体积、模块、缓存
• 实现方式（35%）：能说出 Stats、hooks、telemetry
• 告警与运营（30%）：能说明基线、告警、PR 反馈

常见错误：

• 只关注总耗时，不拆分阶段
• 把 stats.json 全部上传而不做过滤，浪费存储
• 忽略缓存命中率导致重复优化无效方向

延伸追问：

• Webpack 5 persistent cache 的失效场景有哪些？
• 如何在不影响构建速度的前提下采集细粒度指标？

参考资源：

• Webpack Stats Data
• Webpack Compiler Hooks

口头回答版：

Webpack 可观测指标包括阶段耗时、loader/plugin 耗时、产物体积、模块数、缓存命中率。可以用 Stats.toJson 和 compilation hooks 打点，推到 Prometheus。CI 里输出 stats.json，PR 展示体积变化，模块数或体积异常时告警。

---

FB-21-SD-R-090：设计一个面向大型前端 Monorepo 的 Storybook 文档系统

题型：系统设计题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：前端工程化、Storybook 出现频率：高频 预计回答时长：10-15 分钟

题目描述： 某大型前端 Monorepo 包含多个应用和组件库，需要统一的文档系统支持多包版本、主题切换和性能隔离。请给出系统设计。

参考答案：

核心要点：采用 Storybook Composition 实现各包独立构建与统一入口，配合版本化部署、主题共享和 lazy compilation 满足大型 Monorepo 需求。

详细解释：

1. 架构

   • 采用 Storybook Composition，各 package 独立构建自己的 Storybook，最终通过主 Storybook 的 refs 组合。
   • 每个 package 产物部署到独立路径或 CDN。

2. 版本管理

   • 组件库文档按 npm 版本构建，主 Storybook 通过 refs 的 url 指向版本化路径；保留历史版本入口。

3. 主题与品牌

   • 在主 Storybook 通过 globalTypes 和 decorators 提供主题切换。
   • 各 package 继承同一 theme provider，保证视觉一致。

4. 性能隔离

   • 每个 package 单独构建，避免一个包故事过多拖垮全局。
   • 使用 --webpack-stats-json 分析并拆分 chunk；对大型 docs 使用 lazy compilation（--lazy）。

5. 自动化

   • CI 中每个 package 独立构建并上传产物；主 Storybook 在发布时更新 refs 配置。
   • 使用 Chromatic 做视觉回归。

6. 可发现性

   • 主站点提供搜索、包目录、使用率和健康度指标入口。

评分维度：

• 架构设计（35%）：能说明 Storybook Composition、独立构建
• 版本与主题（25%）：能说明版本化部署、主题切换
• 性能隔离（20%）：能提到 lazy compilation、chunk 拆分
• 自动化与治理（20%）：能说明 CI 构建、Chromatic、健康度

常见错误：

• 把所有包的故事放到一个 Storybook 构建
• 不做版本化，升级后旧文档无法查看
• 忽略主题一致性导致文档和实际产品视觉脱节

延伸追问：

• 当某个 package 故事数量达到上千时，如何进一步优化构建时间？
• 如何保证 Composition 后各 package 的全局 decorator 不冲突？

参考资源：

• Storybook Composition
• Chromatic

口头回答版：

用 Storybook Composition，各 package 独立构建，主 Storybook 通过 refs 组合。组件库文档按版本部署，主题用 globalTypes 统一切换。性能上各包独立构建，开大 docs 用 lazy compilation。CI 自动构建上传，Chromatic 做视觉回归。

---

FB-21-CP-R-091：引入 Turborepo 改造 Monorepo 时，如何设计迁移路径、治理策略和度量体系

题型：综合开放题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：Monorepo、Turborepo 出现频率：中频 预计回答时长：10-15 分钟

题目描述： 团队计划从 Multirepo 或松散 Monorepo 迁移到基于 Turborepo 的 Monorepo。请作为技术负责人设计迁移路径、治理策略和度量体系。

参考答案：

核心要点：迁移应分阶段试点、统一工具链、明确包边界与所有权，并通过 DORA/SPACE 指标验证收益。

详细解释：

1. 迁移路径

   • 现状梳理：统计仓库数量、依赖关系、构建脚本、CI 耗时。
   • 试点：选 2-3 个高耦合仓库迁移到同一 workspace，定义 turbo.json pipeline。
   • 工具统一：统一 pnpm workspace、tsconfig references、共享 ESLint/Prettier 配置。
   • 批量迁移：按业务域分批迁移，每批验证 CI 通过率和构建时间。
   • 远程缓存：迁移稳定后启用 Remote Cache，训练团队使用 turbo run。

2. 治理策略

   • 包边界：按业务域分包，禁止跨层引用；用 dependency-cruiser 或 pnpm --filter 检查。
   • 所有者：每个 package 设置 CODEOWNERS 和 package owner。
   • 规范：统一命名、目录结构、发布流程；新 package 需通过模板创建。

3. 度量体系

   • DORA：部署频率、变更前置时间、恢复时间、变更失败率。
   • SPACE：满意度、性能（构建/测试耗时）、活跃度、沟通效率。
   • 指标看板：CI duration、cache hit rate、affected tasks ratio、PR lead time。

评分维度：

• 迁移路径（35%）：能说明现状、试点、批量迁移、远程缓存
• 治理策略（30%）：能说明包边界、CODEOWNERS、模板
• 度量体系（35%）：能给出 DORA/SPACE 和具体指标

常见错误：

• 一次性迁移所有仓库导致长期阻塞
• 只关注构建加速，忽视包边界和所有权
• 缺少度量，无法验证迁移收益

延伸追问：

• 如何处理不同仓库原有版本号策略不一致的问题？
• 当某个 package 依赖循环时，Turborepo 会如何表现？如何解决？

参考资源：

• Turborepo Migration Guide
• DORA

口头回答版：

先梳理现状，选两三个仓库试点 Turborepo，统一 pnpm 和共享配置，再按业务域分批迁移。治理上按域分包、设 CODEOWNERS、统一模板。度量用 DORA 和 SPACE，重点看构建耗时、缓存命中率和 PR lead time。

---

FB-21-CA-R-001：分析一段 GitHub Actions + Turborepo 的 CI 配置，指出远程缓存失效和任务并行化问题

题型：代码分析题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：GitHub Actions、Turborepo 出现频率：高频 预计回答时长：10-15 分钟

题目描述： 以下是某团队使用 GitHub Actions + Turborepo 的配置片段，请分析远程缓存未命中和任务未充分利用并行化的问题。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm install
      - run: npx turbo run build --remote-only
    env:
      TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}

参考答案：

核心要点：该配置存在包管理器不一致、缺少 TURBO_TEAM、--remote-only 风险、未使用 affected、缺少缓存和 runner 固定等问题。

详细解释：

1. 包管理器不一致

   • 项目若使用 pnpm，CI 用 npm 会导致 lock 不生效、依赖版本漂移；应使用 pnpm/action-setup 并 cache: 'pnpm'。

2. 缺少 TURBO_TEAM

   • TURBO_TOKEN 需配合 TURBO_TEAM（或 Vercel team slug）才能定位远程缓存。

3. --remote-only 风险

   • 远程缓存不可用时构建失败；应去掉 --remote-only 或配置本地回退。

4. 未使用 affected

   • 每次 push 都跑全量 build；应使用 npx turbo run build --affected（或 --filter=[origin/main...HEAD]）。

5. 无缓存 key 和 artifact

   • 未缓存 node_modules、Turborepo cache、.next 产物；应使用 actions/cache。

6. runner 标签漂移

   • ubuntu-latest 应固定。

7. 未声明环境变量

   • 若构建依赖 NEXT_PUBLIC_* 等 env，未在 turbo.json 声明会导致缓存键不一致。

评分维度：

• 远程缓存配置（35%）：能指出 TURBO_TEAM、token、--remote-only
• affected 与并行（25%）：能说明 --affected、全量构建问题
• 缓存与一致性（25%）：能提到 pnpm cache、actions/cache、runner 固定
• env 声明（15%）：能说明 turbo.json env

常见错误：

• 认为有 TURBO_TOKEN 就一定能命中缓存
• 忽略包管理器与 lock 一致性
• 建议所有任务都加 --remote-only 以“强制”使用远程缓存

延伸追问：

• 如果不同分支的环境变量不同，如何设计 Turborepo 缓存策略？
• turbo run build --affected 在 CI 中需要哪些 Git 历史？

参考资源：

• Turborepo Remote Caching
• GitHub Actions Workflow Syntax

口头回答版：

主要问题：没配 TURBO_TEAM，--remote-only 没本地回退，包管理器可能不一致，没开 affected，也没缓存。应该用 pnpm action-setup 加缓存，turbo.json 声明 env，runner 固定，去掉 --remote-only 或用 affected 减少任务。

---

FB-21-CD-R-001：请手写一个将 Design Token JSON 转换为 CSS 自定义属性与 TypeScript 类型定义的 Node 工具函数

题型：手写代码题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：组件库、Design Token 出现频率：低频 预计回答时长：10-15 分钟

题目描述： 请手写一个 Node.js/TypeScript 函数，输入为符合 W3C 格式的 Design Token JSON，输出为两个文件：tokens.css（CSS 自定义属性）和 tokens.d.ts（类型定义）。

参考答案：

核心要点：递归展平嵌套 token，将路径转换为 kebab-case 的 CSS 变量名，生成 CSS 和 TypeScript 类型文件。

详细解释：

import { writeFileSync } from 'node:fs';
import { kebabCase } from 'lodash-es'; // 或自行实现

type TokenValue = { $value: string; $type?: string };
type TokenGroup = { [key: string]: TokenValue | TokenGroup };

function isTokenValue(v: unknown): v is TokenValue {
  return typeof v === 'object' && v !== null && '$value' in v;
}

function flattenTokens(
  tokens: TokenGroup,
  prefix = '',
  entries: { name: string; value: string }[] = []
) {
  for (const [key, val] of Object.entries(tokens)) {
    const path = prefix ? `${prefix}-${key}` : key;
    if (isTokenValue(val)) {
      entries.push({ name: kebabCase(path), value: val.$value });
    } else {
      flattenTokens(val as TokenGroup, path, entries);
    }
  }
  return entries;
}

export function buildTokens(input: TokenGroup, outDir: string) {
  const entries = flattenTokens(input);
  const css = `:root {\n${entries.map(e => `  --${e.name}: ${e.value};`).join('\n')}\n}`;
  const types = entries.map(e => `  '--${e.name}': string;`).join('\n');
  const dts = `export interface CSSCustomProperties {\n${types}\n}`;
  writeFileSync(`${outDir}/tokens.css`, css);
  writeFileSync(`${outDir}/tokens.d.ts`, dts);
}

要点：递归展平嵌套 token、kebab-case 命名、生成 CSS 和 TS、可扩展主题选择器。

评分维度：

• 正确性（40%）：能递归解析 token、输出正确 CSS/TS
• 边界处理（25%）：能处理嵌套、非 token 字段、空输入
• 可扩展性（20%）：能支持主题前缀或不同命名策略
• 代码质量（15%）：类型安全、错误处理

常见错误：

• 只处理一层 token，忽略嵌套
• 直接拼接字符串而不做 kebab-case 转换
• 未对 $value 做类型校验

延伸追问：

• 如何扩展该函数支持暗黑模式等主题？
• 如果 token 值引用其他 token，如何处理？

参考资源：

• W3C Design Token Format
• Style Dictionary

口头回答版：

递归展平 token JSON，把路径转成 kebab-case 的 CSS 变量名，然后生成 :root 下的 CSS 和 TS 类型定义。函数要处理嵌套、校验 $value，还能扩展主题前缀。

---

FB-21-FS-R-001：Design Token 的多平台转换原理是什么？如何设计可扩展的 Token 编译管线

题型：框架原理题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：Design Token、Jest 出现频率：高频 预计回答时长：10-15 分钟

题目描述： 请解释 Design Token 从设计源到多平台产物（Web、iOS、Android）的转换原理，并设计一条可扩展的编译管线。

参考答案：

核心要点：基于 W3C 格式的 Token 经解析、alias 解析、平台过滤、类型转换和格式化后输出多平台产物；管线应插件化并支持 diff 校验。

详细解释：

1. W3C 格式

   • token 以 $value、$type、$description 描述，支持 alias（引用其他 token）。

2. 转换管线

   • 解析：读取 JSON，验证 schema，解析 alias。
   • 预处理：按主题（light/dark）和平台过滤 token。
   • 转换：根据 $type 选择 transformer（color → hex/css/rgba，dimension → px/rem/sp，fontFamily → string/array）。
   • 格式化：选择 formatter 生成 CSS、SCSS、iOS .swift、Android .xml、JS/TS。
   • 输出：写入文件并生成 sourcemap/类型定义。

3. 可扩展性

   • 每个 transformer/formatter 注册为插件，通过配置 platforms 启用。
   • 提供 hook（preprocess、transform、format）。

4. 校验

   • 对比上一轮产物 diff，阻止破坏性变更。
   • 用 snapshot 测试锁定输出。

5. 工具

   • Style Dictionary、token-transformer、Cobalt 等。

评分维度：

• 转换原理（35%）：能说明解析、alias、transform、format
• 管线可扩展性（35%）：能说明插件化、平台配置、hook
• 校验与工具（30%）：能提到 diff、snapshot、Style Dictionary

常见错误：

• 把 token 转换当成简单字符串替换
• 不同平台使用同一 formatter 导致单位不匹配
• 忽略 alias 解析导致循环引用或值丢失

延伸追问：

• 如何处理 token 引用链中的循环依赖？
• 当设计师增加新 $type 时，如何最小化代码改动接入？

参考资源：

• Style Dictionary
• Tokens Studio for Figma

口头回答版：

Design Token 先解析 JSON 和 alias，再按平台过滤，然后根据 type 做转换，最后格式化成 CSS、iOS、Android 等产物。可扩展性靠插件化 transformer 和 formatter，通过平台配置启用。还要做 diff 和 snapshot 测试防止破坏性变更。

---

FB-21-SS-R-089：作为技术负责人，你如何推动 Vite + TypeScript 迁移并管理团队的抵触情绪和学习成本

题型：软技能题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：Vite、TypeScript 出现频率：低频 预计回答时长：10-15 分钟

题目描述： 请用具体案例说明你作为前端负责人，如何推动从旧构建工具迁移到 Vite + TypeScript，并处理团队成员的抵触情绪和学习成本。

参考答案：

核心要点：通过量化收益、共创决策、渐进迁移和降低学习成本来推动迁移，并用满意度与效率指标验证效果。

详细解释：

1. 情境

   • 某团队长期使用 webpack + JavaScript，构建慢、类型缺失导致线上 Bug 多；业务方担心迁移影响交付。

2. 任务

   • 在 6 个月内完成核心项目迁移，保证业务交付不受影响，团队接受度 >80%。

3. 行动

   • 数据说服：展示 webpack 构建耗时趋势、近半年由类型缺失导致的 P1 Bug 数量。
   • 共创决策：组织 2 次技术选型工作坊，让核心开发者参与 Vite vs webpack 评估，形成共识。
   • 渐进迁移：新页面用 Vite + TS，老页面逐步迁移；用 vite-plugin-legacy 保证兼容性。
   • 降低学习成本：制作 TypeScript 速查表、Vite 配置 FAQ、结对编程；设置“迁移答疑时间”。
   • 缓冲机制：迁移期间允许老项目继续维护，不强制一刀切。

4. 结果

   • 构建时间从 6 分钟降到 1.5 分钟；TS 覆盖率达到 85%；团队满意度调研 87%。

5. 反思

   • 技术迁移要先把收益量化，并让一线同学参与决策；强制推广容易激发抵触。

评分维度：

• 案例具体（40%）：有数据、时间、团队规模
• 推动策略（30%）：能说明共创、渐进、缓冲
• 学习成本管理（20%）：能提到培训、FAQ、结对
• 收益度量（10%）：有前后对比

常见错误：

• 只强调技术先进，不讲业务收益
• 强制限期迁移，忽视团队反馈
• 没有培训，导致迁移后代码质量下降

延伸追问：

• 如果迁移过程中出现性能回退，你会怎么处理？
• 如何评估一个老页面是否值得迁移？

参考资源：

• Vite Migration from webpack
• TypeScript Adoption Guide

口头回答版：

我先拿构建耗时和类型 Bug 数据说服大家，再组织选型工作坊让核心同学参与。迁移分阶段，新页面用 Vite+TS，老页面逐步迁，同时做 TypeScript FAQ 和结对编程。结果构建从 6 分钟降到 1.5 分钟，TS 覆盖率 85%，团队满意度 87%。

---

FB-21-CO-R-001：Babel 插件体系的可观测性如何设计？如何度量转译耗时与插件影响

题型：概念题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：可观测性、Babel 出现频率：高频 预计回答时长：10-15 分钟

题目描述： 团队在大型项目中使用大量自定义 Babel 插件，转译耗时难以定位。请设计 Babel 插件体系的可观测性方案。

参考答案：

核心要点：通过插件包装器计时、AST 节点计数和 profile 输出，将 Babel 转译耗时与插件影响可视化。

详细解释：

1. 插件包装

   • 写一个 Babel 插件包装器，在 visitor 进入/退出时通过 process.hrtime.bigint() 计时，输出每个插件/visitor 的耗时。

2. AST 节点计数

   • 在 pre/post 中统计进入的节点数，评估插件复杂度和影响范围。

3. 集成到构建

   • 自定义 Babel 配置中按环境开启 BABEL_ENV=profile，输出 JSON profile；在 CI 中归档。

4. 与构建工具联动

   • 在 webpack 中使用 speed-measure-webpack-plugin 看 babel-loader 耗时。
   • 在 Vite 中通过 @vitejs/plugin-react 的 babel 配置注入 profiler。

5. 分析与告警

   • 将 profile 数据写入 metrics 服务，对单个插件耗时突增或 visitor 进入次数异常设置告警。
   • PR 中展示转译耗时 diff。

6. 优化闭环

   • 根据数据禁用/替换低效插件，或将其改为仅在生产构建生效。

评分维度：

• 观测设计（35%）：能说明插件包装、计时、节点计数
• 度量实现（30%）：能给出 profile 输出、CI 归档、metrics
• 工具联动（20%）：能结合 webpack/Vite 采集
• 优化闭环（15%）：能提到告警、diff、插件替换

常见错误：

• 只在总耗时层面优化，不拆分插件
• 对 visitor 做同步高耗时操作导致转译阻塞
• 忽略 AST 节点规模对插件耗时的影响

延伸追问：

• 如何在不污染业务代码的前提下注入 profiler？
• Babel 的 pre/post 和 visitor 的执行顺序是什么？

参考资源：

• Babel Plugin Handbook
• Babel Options

口头回答版：

用包装器给每个 Babel 插件的 visitor 计时，统计 AST 节点数，输出 JSON profile。CI 里归档，结合 webpack 的 speed-measure 看 babel-loader。数据推到 metrics，插件耗时突增就告警，再决定禁用或替换。

---

FB-21-SC-R-001：如何为前端团队设计基于 GitHub Actions 与 Docker 的云端开发/CI 一体化环境

题型：场景设计题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：GitHub Actions、Docker 出现频率：高频 预计回答时长：10-15 分钟

题目描述： 团队开发者本地环境差异大，CI 也频繁出现“本地能跑 CI 失败”。请设计一套基于 GitHub Actions 和 Docker 的云端开发与 CI 一体化方案。

参考答案：

核心要点：通过统一 Docker 镜像、Dev Container、CI 复用同一镜像和分层缓存，实现本地与云端环境一致。

详细解释：

1. 统一镜像

   • 维护团队基础 Docker image（包含 Node、pnpm、浏览器、系统依赖），版本号与仓库 lockfile 对齐。
   • 镜像推送到 GitHub Container Registry。

2. Dev Container

   • 提供 .devcontainer/devcontainer.json 使用该镜像，支持 VS Code / Codespaces。
   • 本地开发者可选进入容器开发。

3. CI 复用镜像

   • GitHub Actions 中 container: ghcr.io/team/frontend-dev:1.2.0，保证 CI 与本地容器完全一致。

4. 缓存层

   • Dockerfile 分层，先 COPY lockfile 安装依赖，再 COPY 源码。
   • CI 中缓存 Docker layer 和 pnpm store。

5. 权限与 secrets

   • 镜像仓库私有，CI 通过 GITHUB_TOKEN 拉取。
   • secrets 只在 CI 注入，不进入镜像。

6. 一体化体验

   • Codespaces 预装推荐扩展，post-create 自动安装依赖。
   • 提供 devcontainer exec 脚本让本地用户无需 Codespaces 也能用同一镜像。

评分维度：

• 镜像设计（30%）：能说明基础镜像、版本对齐、分层
• Dev Container 与 CI 复用（30%）：能说明 devcontainer.json、container image
• 缓存与权限（25%）：能提到 Docker layer cache、pnpm store、镜像私有
• 开发者体验（15%）：能说明 Codespaces、本地 fallback

常见错误：

• CI 和本地使用不同 Dockerfile
• 把 secrets 硬编码进镜像
• 镜像体积过大导致启动慢

延伸追问：

• 如何在 Docker 镜像中管理不同项目的 Node 版本？
• 如果开发者网络慢，如何加速 Docker 镜像拉取？

参考资源：

• GitHub Container Registry
• Dev Containers

口头回答版：

维护一个团队基础 Docker 镜像，包含 Node、pnpm、浏览器，版本和 lockfile 对齐。本地用 Dev Container，CI 用同一个镜像。Dockerfile 分层安装依赖，缓存 layer 和 pnpm store。镜像私有，secrets 不放进镜像。Codespaces 里预装扩展，本地也可以跑 devcontainer exec。

---

FB-21-PE-R-001：大型 TypeScript 仓库中 tsc 类型检查极慢，如何从架构层面系统排查与优化

题型：性能优化题 难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：21 开发者体验 标签：TypeScript、脚手架 出现频率：中频 预计回答时长：10-15 分钟

题目描述： 某大型 TypeScript Monorepo 中，tsc --noEmit 耗时超过 10 分钟，严重影响 CI 反馈。请给出从架构层面排查和优化的完整思路。

参考答案：

核心要点：通过 tsconfig 拆分、Project References、依赖图优化、增量与缓存、并行分片等手段，从架构层面降低类型检查耗时。

详细解释：

1. 拆分 tsconfig

   • 根目录 tsconfig.base.json 放公共严格规则；每个 package 有自己的 tsconfig.json 和 tsconfig.build.json，明确 include/exclude。

2. Project References

   • 启用 composite: true，让 tsc 只检查变更包及其依赖。
   • 使用 tsc --build 增量编译。

3. 依赖图优化

   • 减少 package 间循环依赖；将大型类型定义拆分为独立 package。
   • 避免 barrel export 导致的类型解析扩大。

4. 加速选项

   • 开启 skipLibCheck: true（库项目谨慎）；incremental: true；tsBuildInfoFile 指向缓存目录；CI 中缓存 .tsbuildinfo。

5. 并行与分布式

   • 按 package 分片在 CI 中并行跑类型检查。
   • 使用 Nx/Turborepo affected 只检查变更包。

6. 转译与类型分离

   • 开发时用 SWC/esbuild 转译，类型检查由 IDE/CI 单独跑；避免 fork-ts-checker 阻塞 dev server。

7. 度量

   • 记录每个 package 的类型检查耗时，找出热点；对增长快的包设置预算。

评分维度：

• 架构拆分（35%）：能说明 base、project references、composite
• 依赖与范围（25%）：能提到循环依赖、barrel export、include/exclude
• 加速手段（25%）：能说明 skipLibCheck、incremental、缓存、affected
• 度量与治理（15%）：能给出 package 耗时预算

常见错误：

• 全仓库用一个 tsconfig，include 范围过大
• 一次性开启所有严格检查导致无法完成
• 把类型检查放在构建主线程阻塞 CI

延伸追问：

• skipLibCheck: true 会隐藏哪些风险？如何在库项目中权衡？
• Project References 和 tsc --build 的增量机制有什么区别？

参考资源：

• TypeScript Project References
• TypeScript Performance

口头回答版：

先用 project references 拆分 tsconfig，每个包独立 composite。优化依赖图，减少循环和 barrel export。开 incremental、skipLibCheck，CI 缓存 .tsbuildinfo。用 Nx/Turborepo affected 只检查变更包，开发时类型检查单独跑。还要度量每个包的耗时，设预算。

---