回答整体思路（你可以先记住这个结构）
- 先总述：一两句话概括你对组件库和 Wot UI 的整体经验
- 再拆成三块：
- 常见组件库的使用经验
- 对组件库设计思想 / 架构的理解
- 在 Wot UI 做过的具体事情和案例
- 最后收尾：说自己能把这套经验带到新团队，落地业务组件库或提升现有组件库
下面我按「面试官可能会问什么」+「建议回答示例」来帮你准备，你可以选几段背成自己的话。
1. 面试官可能的第一问：你熟悉哪些组件库？具体是怎么用的？
目的：验证你是否真的用过主流组件库，以及用得有多深入。
可以这样答：
简要列举+场景化
- 我日常比较熟悉的有 XXX、XXX（比如：Element Plus / Ant Design / Vant / Naive UI 等，按你真实情况说）。
- 一般会在中后台项目里用 XX，在移动端或小程序里用 XX，主要负责页面搭建、复杂表单、弹窗流程、列表筛选等需求。
强调「不仅会用，还会封装」
- 在项目中不会直接裸用组件库，而是结合业务做二次封装，比如统一表单校验规则、统一弹窗行为、统一主题色，避免每个页面重复配置。
- 遇到组件库不满足需求的情况，会基于它的基础组件或样式变量自己封一层。
示例回答（可直接背）：
- 我常用的有 A、B、C 这些组件库，在中后台项目和移动端项目里都有落地过。
- 平时不仅是“会调 API 搭界面”，更多是基于这些组件库做业务级封装，比如把表单、弹窗、列表这些高频场景抽成通用组件，统一交互和样式，减少重复开发。
- 通过大量使用主流组件库，我也积累了一些对组件库 API 设计、交互细节、扩展性的理解，这些都在后面做 Wot UI 的时候有用到。
2. 说说你理解的组件库设计思想和架构？
目的：验证你是不是停留在“调用 API”层面，还是理解过背后的设计。
你可以从这几个点来讲：
组件库的目标
- 提升开发效率：高复用、减少重复造轮子
- 保证体验一致：视觉规范、交互一致性
- 可维护可演进：版本升级不崩、易扩展、支持自定义主题
设计原则
- API 简单直观：常用场景开箱即用，复杂场景可扩展
- 高内聚低耦合：组件之间尽量解耦，通过事件、插槽、props 通信，而不是互相硬引用
- 向下兼容：尽量避免破坏性变更，有破坏性变更要有 deprecate 方案
- 可配置 / 可定制：支持主题定制、样式变量、全局配置等
架构层次（重点）
- 基础层：设计变量（颜色、间距、字号）、基础样式、基础动画等
- 工具层：工具函数（节流、防抖、DOM 操作）、通用 hooks、内部事件总线等
- 基础组件：Button / Input / Toast / Dialog / Tabs 等通用 UI 组件
- 业务组件（如果有）：如表单封装、表格封装等
- 工程层：文档站、按需加载、Tree Shaking、单元测试、CI、版本管理、跨端兼容（对 uni-app、小程序、H5 等）
示例回答（偏精简版）：
- 我理解的组件库，首先是要在“提升开发效率”和“保持体验一致”之间做平衡。
- 在设计思想上会坚持 API 简单直观、高内聚低耦合、强调向下兼容和可扩展性，常用场景开箱即用，复杂场景提供扩展能力。
- 架构上一般会分几层：底层有设计变量和基础样式，中间是工具函数和通用 hooks，上面是一个个基础组件，再往上会有一些业务级封装。外面还有工程层面的文档、按需打包、测试和 CI。
- 在做 Wot UI 的时候，我们也是按这种分层来做的，比如先沉淀一套统一的设计变量，再基于这些变量去搭建 Button、Toast 这些基础组件。
3. 面试官重点追问：你在 Wot UI 具体做了什么？
这里一定要说「具体事情 + 问题 + 解决方案 + 结果」，别只说“参与设计开发维护”。
你可以从三类内容来准备：
1）负责的模块 / 组件
- 举例：
- 参与了 XXX、XXX 等组件的设计和开发（比如 Toast、Popup、Form、Tabs 等，按你真实经历说）
- 做过一些全局性的能力，比如：全局配置、主题定制、国际化支持、按需引入优化等
示例说法：
- 在 Wot UI 里，我主要参与了若干基础组件和反馈类组件的设计开发，比如 Toast / Dialog / Tabs 等。
- 从需求评审、API 设计、交互细节、到编码实现、文档编写、线上 bug 维护这条链路都有参与。
2）挑 1–2 个代表性案例展开讲
比如你可以拿一个「Toast 组件」这样的反馈类组件来说（和你现在打开的文件也对应上）：
需求与目标
- 支持全局调用（如
Toast.success('')这种） - 支持不同平台（H5、小程序、uni-app）
- 需要队列 / 多实例处理、自动关闭、遮罩、点击穿透等问题
- 支持全局调用（如
设计与实现思路
- 设计统一的 Options：type、duration、position、mask、icon 等
- 提供组合 API：
show / success / error / loading，内部统一走一个渲染逻辑 - 处理多次调用：是选择队列，还是只保留最新一条？怎么保证动画不要抖动
- 做了哪些跨端兼容处理
结果
- 在业务项目里大量复用，减少了重复封装
- 有哪些线上 bug，通过优化组件解决了（比如：某端 Toast 位置错乱、滚动穿透、关闭不及时等）
示例回答（可以背一个简化版）：
- 在 Wot UI 里我印象比较深的是做 Toast 这类反馈组件。
- 一开始的需求是要支持全局调用、跨端适配，还要考虑多次调用时的展示策略。
- 我在设计上先抽象了一套统一的 Options（比如 type、duration、position、是否有遮罩等），对外暴露
show / success / error / loading这类方法，内部都复用同一套渲染逻辑，既保证 API 简单，又便于维护。 - 为了避免多次调用导致的动画抖动和覆盖问题，我在内部做了实例管理和调用节制，默认只展示最新的一条，特殊场景才排队展示。
- 后面在业务里大量用这个组件，基本不用再为每个项目单独封装 Toast，统一修一处 bug 就能全局收益。
3）维护 & 质量保障
- 你可以强调：
- 写了单元测试 / E2E 测试，覆盖组件的核心行为
- 接入 CI，在 PR 阶段跑 lint 和测试
- 对用户反馈的 issue，会定位问题、写复现 demo、产出修复 PR 和 changelog
示例说法：
- 在维护上，我会针对关键组件补充单元测试，比如交互类组件的显示隐藏逻辑、边界参数处理等，保证后续重构不容易引入回归。
- 也参与了部分 issue 的跟进，习惯先用最小复现仓库把问题还原出来，再去排查是使用方式问题还是组件库实现上的 bug，然后提交修复 PR 并更新文档和 changelog。
4. 可能追问：如果让你从零设计一个组件库，你会怎么做？
这类问题很常见，你可以用「步骤法」来答：
第一步：统一设计规范
- 先和设计、团队确认一套基础设计规范：颜色、字号、间距、圆角、状态（悬浮、点击、禁用等）。
- 没有设计也没关系，可以先抽象出一套基础 token，后面再渐进式完善。
第二步：梳理组件列表和优先级
- 从业务项目中抽象高频场景，先做 Button / Layout / Form / Dialog / Toast 等基础组件。
- 逐步再覆盖 Tabs、Dropdown、Table 等。
第三步：设计 API 和交互
- 尽量对齐社区习惯（比如 props 命名、事件命名习惯），降低学习成本。
- 先把 80% 高频场景做到“零配置/弱配置”，复杂场景通过插槽、render 函数、扩展 props 支持。
第四步：工程化和发布
- 搭建按需加载、Tree Shaking 的构建方案；
- 支持类型声明、自动文档生成、Demo 预览；
- 做好测试、CI、版本管理和 changelog。
示例回答：
- 如果从零做组件库，我会先从设计规范入手，和设计 / 团队确定颜色、间距、字号等基础 token，然后基于这套规范去设计基础组件。
- 在 API 上尽量对齐社区主流组件库的使用习惯，降低上手成本，同时通过插槽和扩展 props 提供灵活性。
- 工程层面会一开始就考虑按需加载、类型支持和自动化测试，这样后续演进和对外升级成本更可控。
- 在 Wot UI 的实践里，其实就是沿着这条思路，一边抽象组件，一边不断完善底层能力和工程体系的。
5. 可能追问：你做组件库时踩过什么坑？怎么解决的？
准备 1–2 个「坑+解决方案」很加分。
你可以举类似下面的例子（按你实际情况改）：
跨端兼容坑（特别是 uni-app / 小程序 / H5）
- 不同端对某些 CSS 特性、事件行为处理不一致，导致组件在某端表现异常。
- 解决：抽象适配层，或者针对不同端做轻量分支处理，并在文档里说明限制。
API 设计不当导致后续难以维护
- 早期 API 设计没考虑好扩展性，后来需求多了只能新增很多 props 或用奇怪的组合。
- 解决：迭代 API，增加更通用的配置方式，同时保证兼容老版本，通过 deprecate 提示引导用户迁移。
示例回答：
- 做组件库过程中也踩过一些坑，比如在多端适配时，同一段样式在小程序上表现和 H5 不一致，导致组件在某端出现错位。后来我把这类差异抽到适配层，统一管理不同端的差异处理，同时在文档里明确标注哪些特性在哪些端有差异。
- 还有 API 设计的问题，一开始某个组件的 API 设计得比较“针对场景”，后面需求一多就会堆 props。后来我在不破坏现有用法的前提下，加了一层更通用的配置方式，并在文档和 changelog 里给出迁移建议，逐步引导用户用新的 API。
6. 把这些内容浓缩成你简历点的口头版
最后你可以准备一个 30–60 秒的「总结版」，在面试官顺着简历问时直接说：
示例总结（建议背熟）：
- 关于组件库这块，我之前在项目里大量使用过主流组件库，也基于它们做过业务级的二次封装，所以对组件库的 API 设计、交互细节和扩展性有一些实践经验。
- 后面参与了开源组件库 Wot UI 的设计和开发维护，主要负责一些基础组件和反馈组件，比如 Toast、Dialog、Tabs 等，从需求评审、API 设计、编码实现到文档和 bug 维护都有参与。
- 在这个过程中，我更多关注组件库的整体设计思想和架构，比如统一设计变量、分层抽象、按需加载和测试体系，也踩过一些多端适配和 API 设计的坑，并通过重构和文档规范来解决。
- 这些经验可以帮助我在新团队里更好地使用和改造现有组件库，或者参与到自研组件库的建设中。
如果你愿意，你可以把你在 Wot UI 里真正做过的 2–3 个组件和问题点告诉我，我可以帮你改写成更贴合你真实经历、可以直接在面试中用的答案。