设计体系面试题

基础题

1. 什么是设计体系？它包含哪些内容？基础

参考答案：

设计体系（Design System）是把产品的设计语言、组件、工具、文档与最佳实践系统化整合后形成的一套“单一事实来源”。它让设计师与开发者在不同项目、不同团队中都能产出一致的用户体验。

核心组成：

1. 设计原则：品牌调性、可用性准则、体验目标。
2. Design Token：颜色、字体、间距、圆角、阴影等可复用的设计变量。
3. 基础组件库：Button、Input、Select、Modal 等原子/分子级组件。
4. 模式与模板：常见页面布局、表单模式、空状态、错误状态等复合模式。
5. 设计资源：Figma/Sketch 组件库、图标库、插画规范。
6. 文档与示例：使用说明、最佳实践、代码示例、可访问性指南。
7. 工具链：Storybook、Token 管理工具、Lint 插件、代码生成器。

价值：提升一致性、加速交付、降低维护成本、支持多品牌/多端扩展。

评分维度：

• 能解释设计体系概念（30%）
• 能说出 4 个以上组成部分（40%）
• 能说明对团队和产品的价值（30%）

---

2. 原子化设计的五个层级是什么？基础

参考答案：

原子化设计（Atomic Design）由 Brad Frost 提出，把 UI 拆分为五个层级：

1. Atoms（原子）：最基础、不可再分的元素，如颜色、字体、图标、按钮本身。
2. Molecules（分子）：由原子组合成的简单功能单元，如搜索框（Input + Icon + Button）。
3. Organisms（有机体）：由分子和原子组成的较复杂组件，如 Header、Card、表单区块。
4. Templates（模板）：页面骨架，展示组件如何排版，但使用占位数据。
5. Pages（页面）：填充真实数据后的具体页面，是模板的实例化。

这种分层让设计资产与代码组件一一映射，便于复用、测试和迭代。

评分维度：

• 能说出 5 个层级（40%）
• 能举例说明各层级（40%）
• 能说明分层带来的工程价值（20%）

---

3. 什么是 Design Token？基础

参考答案：

Design Token 是用于存储设计决策的变量，把颜色、字号、间距、圆角、阴影等视觉值抽象为具有语义化命名的键值对。

示例：

{
  "color-primary": "#1677ff",
  "color-text-secondary": "rgba(0,0,0,0.65)",
  "spacing-md": "16px",
  "radius-base": "6px"
}

作用：

• 一致性：一处修改全局生效。
• 主题化：通过替换 Token 实现品牌换肤、暗黑模式。
• 跨平台共享：同一套 Token 可同步给 Web、iOS、Android、小程序。
• 设计与代码对齐：设计稿与组件库使用同一套命名，减少沟通成本。

评分维度：

• 能解释 Design Token 概念（30%）
• 能举例说明 Token 形式（30%）
• 能说出 3 个以上作用（40%）

---

4. Storybook 有什么作用？基础

参考答案：

Storybook 是组件的开发、测试与文档化工作台，核心价值包括：

1. 独立开发：无需启动完整应用即可单独查看和调试组件。
2. 状态展示：通过多个 Story 展示组件在不同 props、状态、尺寸下的表现。
3. 交互测试：结合 @storybook/addon-interactions 验证用户交互行为。
4. 自动生成文档：基于组件 prop 类型和注释生成 API 文档。
5. 视觉回归测试：配合 Chromatic、Percy 等工具检测 UI 意外变化。
6. 设计-开发协作：设计师可在 Storybook 中直接查看组件实现效果。

示例：为 Button 编写 primary、disabled、loading、size 等多个 Story。

评分维度：

• 能解释 Storybook 定位（30%）
• 能说出 3 个以上作用（40%）
• 能举例说明 Story 的应用（30%）

---

5. 可访问性（a11y）为什么重要？基础

参考答案：

可访问性（Accessibility，简称 a11y）指产品对所有用户都可用，包括视障、听障、行动不便、老年用户等。

重要性：

1. 用户平等：互联网应为所有人服务，残障用户也有权使用产品。
2. 法律合规：许多国家有相关法律（如美国 ADA、欧洲 EAA），不符合可能带来诉讼风险。
3. 体验提升：良好的可访问性设计往往也提升了普通用户的使用体验，如清晰的对比度、键盘导航。
4. SEO 友好：语义化 HTML、alt 文本等同时对搜索引擎更友好。
5. 品牌责任：体现企业的社会责任感。

实践：

• 使用语义化 HTML 标签（<button>、<nav>、<main>）。
• 保证键盘可达：Tab 聚焦、Enter/Space 触发、Esc 关闭。
• 正确补充 ARIA 属性（aria-label、aria-expanded、aria-describedby）。
• 颜色对比度满足 WCAG AA 标准（正文 4.5:1，大文字 3:1）。
• 为图片提供有意义的 alt 文本。
• 使用屏幕阅读器（VoiceOver、NVDA）验证体验。

// 可访问按钮示例
<button
  aria-label="关闭弹窗"
  onClick={onClose}
>
  ×
</button>

评分维度：

• 能解释可访问性概念（25%）
• 能说明 3 个以上重要性（35%）
• 能举例实践方法（30%）
• 有代码示例（10%）

---

进阶题

6. 对比 BEM、CSS Modules、CSS-in-JS、原子化 CSS。进阶

参考答案：

方案	核心思想	优点	缺点	适用场景
BEM	块-元素-修饰符命名约定	命名清晰、无冲突	类名冗长、依赖人遵守	传统项目、无构建工具
CSS Modules	构建时自动 hash 局部类名	作用域隔离、零运行时开销	动态样式、全局样式需特殊处理	React/Vue 组件化项目
CSS-in-JS	在 JS 中写样式，运行时生成类名	动态样式强、主题化方便、Tree Shaking	运行时开销、包体积增加	强主题化、组件库
原子化 CSS	每个类对应单一样式规则	产物小、开发快、一致性高	类名冗长、复杂样式难表达	快速开发、中后台

选型建议：

• 需要强运行时主题和组件库 → CSS-in-JS（如 styled-components、Emotion）。
• 追求性能和零运行时开销 → CSS Modules 或 Tailwind-like 原子化 CSS。
• legacy 项目 → BEM 作为过渡。

评分维度：

• 能对比四种方案（40%）
• 能从至少 3 个维度说明优缺点（30%）
• 能给出选型建议（30%）

---

7. 组件库设计应该遵循哪些原则？进阶

参考答案：

设计组件库时应遵循以下原则：

1. 单一职责：每个组件只做一件事，功能边界清晰。
2. 可组合性：通过 props、slots/children、render props 支持灵活组合。
3. 可预测性：相同输入产生相同输出，行为符合用户心智模型。
4. 受控与非受控并存：如 Input 同时支持 value + onChange 和 defaultValue。
5. 可访问性：内置键盘导航、ARIA、焦点管理、颜色对比度。
6. 可文档化：每个组件都对应 Story、API 说明和示例。
7. 向后兼容：遵循 SemVer，破坏性变更提供迁移指南。
8. 可扩展性：允许业务通过配置、主题、插槽进行定制，而不需要 fork 源码。

评分维度：

• 能说出 4 个以上原则（40%）
• 能结合实际说明（30%）
• 能提到可访问性与向后兼容（30%）

---

8. 如何设计一个支持主题化的组件库？进阶

参考答案：

主题化的关键是“样式值与组件解耦，通过 Token 驱动”。

设计要点：

1. Token 分层：
   • Global Token：基础色板、字号阶梯。
   • Alias Token：语义化别名，如 color-primary、color-text。
   • Component Token：组件级 Token，如 button-primary-bg。
2. 运行时/编译时切换：
   • 编译时：CSS 变量 + 类名切换，性能最好。
   • 运行时：Context/ConfigProvider 注入主题对象，适合动态换肤。
3. 组件不硬编码具体值：所有样式引用 Token 或 CSS 变量。
4. 支持暗黑模式：通过 prefers-color-scheme 或手动切换 dark class。
5. 类型约束：TypeScript 类型化 Token，防止拼写错误。

示例（CSS 变量 + TypeScript）：

:root {
  --color-primary: #1677ff;
  --color-text: rgba(0, 0, 0, 0.88);
}
[data-theme="dark"] {
  --color-primary: #4d93ff;
  --color-text: rgba(255, 255, 255, 0.85);
}
.btn-primary {
  background: var(--color-primary);
  color: var(--color-text);
}

// React 中切换主题
function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');
  useEffect(() => {
    document.documentElement.setAttribute('data-theme', theme);
  }, [theme]);
  return <ThemeContext.Provider value=&#123;&#123; theme, setTheme &#125;&#125;>{children}</ThemeContext.Provider>;
}

评分维度：

• 能说明 Token 分层（25%）
• 能说明运行时/编译时切换方案（25%）
• 能给出代码示例并提到暗黑模式（35%）
• 提及类型约束（15%）

---

9. 组件库的版本管理应该注意什么？进阶

参考答案：

组件库版本管理直接影响成千上万业务方的升级成本，应格外谨慎：

1. 遵循 SemVer：
   • Patch：Bug 修复，完全兼容。
   • Minor：新增功能，向下兼容。
   • Major：破坏性变更，需迁移指南。
2. 提前标记废弃：对将移除的 API 先 deprecation 警告，保留至少一个 Major 周期。
3. 提供迁移指南：Major 升级必须提供详细的升级文档和 codemod（自动迁移脚本）。
4. 维护 Changelog：使用 Changesets 或 standard-version 自动生成变更日志。
5. 预发布版本：通过 alpha/beta/rc 让社区提前验证。
6. 锁定依赖：避免组件库依赖的第三方包版本漂移导致业务方构建不一致。
7. 文档同步：版本发布时同步更新文档站点和 Storybook。

评分维度：

• 能说明 SemVer 规范（30%）
• 能说明破坏性变更处理（30%）
• 能提到迁移指南、Changelog、预发布（40%）

---

10. 如何保证组件库的质量？进阶

参考答案：

组件库质量需要从设计、开发、测试、发布全流程保障：

1. 设计走查：组件设计稿经过设计师与开发者共同评审，确保视觉与交互一致。
2. 单元测试：覆盖 props 变化、事件回调、边界状态。
3. 视觉回归测试：用 Chromatic/Percy 对比每个 PR 的截图差异。
4. 可访问性测试：使用 axe-core、Storybook a11y addon 检测问题。
5. TypeScript 类型：完整导出 props 类型，避免业务方使用错误。
6. 跨浏览器测试：在主流浏览器验证样式与行为。
7. 文档与示例：每个组件有清晰使用说明和交互示例，减少误用。
8. 自动化发布与门禁：CI 中跑测试、构建、类型检查，失败禁止发布。
9. 用户反馈闭环：建立 issue 模板和 RFC 流程，及时响应业务诉求。

评分维度：

• 能说出 4 种以上方法（40%）
• 能说明测试策略（30%）
• 能提到文档化与自动化发布（30%）

---

高级题

11. 如何从零搭建一个组件库？深入

参考答案：

搭建组件库的关键步骤：

1. 明确目标与范围：服务哪些业务、支持哪些框架、是否需要多端。
2. 选型技术栈：React/Vue、TypeScript、构建工具（Rollup/Vite）、测试框架（Vitest/Jest）。
3. 设计 Token 与基础样式：先定义颜色、字号、间距等原子 Token。
4. 搭建工程化：
   • Monorepo 或单仓库分包；
   • ESLint/Prettier/TypeScript 配置；
   • 打包输出 ESM/CJS/UMD 与 .d.ts。
5. 开发基础组件：Button、Input、Icon 等，遵循受控/非受控、可访问性原则。
6. Storybook 文档化：每个组件编写 Story 和 MDX 文档。
7. 测试体系：单元测试 + 视觉回归 + 可访问性测试。
8. CI/CD 与发布：自动测试、Changesets 版本管理、npm 发布、文档站点部署。
9. 推广与治理：编写接入指南、收集反馈、制定贡献规范。

评分维度：

• 能说出 5 个以上步骤（40%）
• 能说明关键决策点（30%）
• 能提到测试、文档、CI/CD（30%）

---

12. 设计体系和业务需求之间如何平衡？深入

参考答案：

设计体系不是束缚业务，而是提供“有纪律的灵活性”。平衡方式：

1. 覆盖 80% 常见场景：设计体系提供基础组件和模式，满足大部分需求。
2. 保留扩展机制：通过主题、配置、slots、自定义样式类允许业务创新。
3. 建立贡献与审核流程：业务方需要的通用组件可反哺设计体系，避免重复造轮子。
4. 定期收集业务反馈：通过 RFC、问卷、走查了解设计体系是否满足业务。
5. 分阶段推广：先在核心项目验证，再推广到全公司。
6. 允许例外：对 truly one-off 的需求，允许业务自定义，不强求使用组件库。

评分维度：

• 能说明规范与灵活的平衡（40%）
• 能说明反馈与贡献机制（30%）
• 能结合实际场景说明（30%）

---

13. 原子化 CSS 的优缺点是什么？深入

参考答案：

原子化 CSS（如 Tailwind、UnoCSS）把样式拆分为最小的原子类，每个类对应单一 CSS 属性。

优点：

• 产物体积小：只打包使用到的原子类，天然 Tree Shaking。
• 开发速度快：无需命名类名，直接在 HTML 中组合。
• 一致性高：全部基于设计 Token，避免魔法值。
• 避免样式冲突：每个类职责单一，几乎不会出现 specificity 战争。

缺点：

• 类名冗长：HTML 可读性下降，需要工具折叠。
• 复杂样式难表达：复杂选择器、动画、伪类需要额外处理。
• 设计能力要求高：需要熟悉 Token 体系。
• 团队协作成本：新成员需要适应新的写法。

选型：适合快速迭代、设计规范清晰的项目；对高度定制化视觉需求，需评估是否合适。

评分维度：

• 能说出 3 个以上优点（30%）
• 能说出 3 个以上缺点（30%）
• 能给出选型建议（40%）

---

14. 如何处理组件库的多端一致性？深入

参考答案：

多端一致性不是让各端完全一致，而是让“设计语言一致、交互体验一致、代码语义一致”。

实现方式：

1. 统一 Design Token：颜色、字号、间距、圆角在各端共享同一套 Token。
2. 抽象跨端公共组件：对 Button、Input 等基础组件定义统一的 API 规范，各端各自实现渲染。
3. 适配层：把平台差异封装在适配层，业务代码调用统一接口。
4. Design System 文档：明确各端实现差异和允许的差异范围。
5. 跨端视觉回归测试：在 Web、小程序、RN 等端截取关键页面对比。
6. 允许平台特定实现：如原生手势、键盘交互可在各端保持平台特性。

评分维度：

• 能说明统一 Design Token（30%）
• 能说明适配层与统一 API（30%）
• 能说明测试策略与允许差异（40%）

---

15. 设计体系推广过程中可能遇到哪些阻力？深入

参考答案：

常见阻力与应对：

1. 设计师与开发者协作不畅：建立双周同步机制，统一设计 Token 命名与组件 API。
2. 现有项目迁移成本高：提供 codemod、迁移指南，优先在新项目试点。
3. 组件不够灵活：引入主题、slots、自定义渲染函数，满足个性化需求。
4. 文档不完善：投入专人维护文档、示例和 FAQ。
5. 缺乏专人维护：设立 Design System 核心组或虚拟团队，明确 owner。
6. 团队习惯难以改变：通过培训、内部分享、标杆项目证明价值。
7. 业务方质疑 ROI：用数据说明组件复用率、上线速度提升、Bug 率下降。

评分维度：

• 能说出 4 个以上阻力（40%）
• 能给出应对措施（40%）
• 能说明试点与数据验证（20%）

---

补充题

16. 什么是设计 Token 的层级结构？基础

参考答案：

Token 通常分为三层：

1. Global Token（全局 Token）：最基础的设计值，如 #1677ff、14px、4px。一般不由业务直接使用。
2. Alias Token（别名 Token / 语义 Token）：对 Global Token 的语义化封装，如 color-primary、font-size-base、spacing-sm。业务代码主要使用这一层。
3. Component Token（组件 Token）：针对具体组件的 Token，如 button-primary-bg、input-border-color。用于精细控制组件外观，便于主题化和组件级定制。

示例：

{
  "global": { "blue-6": "#1677ff" },
  "alias": { "color-primary": "{blue-6}" },
  "component": { "button-primary-bg": "{color-primary}" }
}

评分维度：

• 能说出三层结构（40%）
• 能举例说明各层（40%）
• 能说明分层带来的可维护性（20%）

---

17. 组件库打包应该输出哪些格式？基础

参考答案：

为了兼容不同使用场景，组件库通常输出：

1. ESM（ES Modules）：现代浏览器和构建工具（Vite、Webpack 5）默认使用，支持 Tree Shaking。
2. CJS（CommonJS）：Node 环境、SSR、Jest 测试等场景需要。
3. UMD（Universal Module Definition）：浏览器直接通过 <script> 引入，适合 CDN 分发。
4. 类型声明文件（.d.ts）：TypeScript 用户需要，支持类型提示和编译校验。
5. CSS 产物：单独的 CSS 文件或 CSS-in-JS 产物。
6. Source Map：便于调试。

现代组件库可以逐步放弃 UMD，改为 ESM + CJS 为主，配合 CDN 的 ESM 入口。

评分维度：

• 能说出 3 种以上格式（40%）
• 能说明每种格式用途（40%）
• 能提到现代趋势（20%）

---

18. 什么是视觉回归测试？基础

参考答案：

视觉回归测试（Visual Regression Testing）通过截图对比检测 UI 的意外变化。它在组件库和关键页面中尤为重要，能发现样式被意外修改、布局错位、颜色偏差等问题。

流程：

1. 在基线版本中截取组件或页面截图。
2. 在变更后再次截图。
3. 使用像素对比或 AI 对比找出差异。
4. 人工确认差异是预期变更还是回归 Bug。

常用工具：Chromatic、Percy、Applitools、Storybook 的视觉测试插件。

注意：对于动画、日期、随机内容等不稳定元素，需要设置忽略区域或 Mock。

评分维度：

• 能解释概念（40%）
• 能说明流程（30%）
• 能列举工具与注意事项（30%）

---

19. 如何提高组件的可访问性？基础

参考答案：

提高组件可访问性的实践：

1. 语义化 HTML：使用 <button> 而非 <div> 做按钮，使用 <nav>、<main> 等结构化标签。
2. 键盘可达：所有可交互元素支持 Tab 聚焦、Enter/Space 触发、Esc 关闭。
3. ARIA 属性：在必要时补充 role、aria-label、aria-expanded、aria-describedby。
4. 焦点管理：Modal 打开时聚焦到首元素，关闭时回到触发元素。
5. 颜色对比度：文本与背景对比度满足 WCAG 标准（AA 级 4.5:1）。
6. 替代文本：图片提供有意义的 alt，装饰性图片设为空 alt。
7. 屏幕阅读器测试：使用 VoiceOver、NVDA 验证组件朗读效果。

评分维度：

• 能说出 4 个以上实践（40%）
• 能说明 ARIA 与焦点管理（30%）
• 能提到 WCAG 对比度标准（30%）

---

20. 你认为一个好的设计体系应该具备什么特点？基础

参考答案：

一个好的设计体系应具备：

1. 一致性强：视觉、交互、文案在不同产品、不同端保持一致。
2. 易于使用：文档清晰、示例丰富、API 直观，降低接入门槛。
3. 可扩展：支持主题、定制、新业务快速接入。
4. 可维护：有明确 owner、版本管理、贡献规范和升级流程。
5. 文档完善：设计原则、Token、组件 API、最佳实践齐全。
6. 可访问性好：默认支持键盘、屏幕阅读器、高对比度。
7. 与业务紧密结合：不是脱离业务的美学规范，而是能解决真实问题。
8. 持续演进：根据业务反馈和技术发展不断更新。

评分维度：

• 能说出 4 个以上特点（40%）
• 能结合实际说明（30%）
• 能体现系统性思维（30%）

---

领域编号：E05 设计体系
最后更新：2026-06-18