01

60 秒回答模板

设计组件我会先问它解决什么稳定问题，是否值得抽象。确定后再定义职责边界：组件负责 UI 展示、交互状态和通用逻辑，业务页面负责接口、路由、权限和埋点。API 上要设计清楚 props、events、slots、默认值和受控/非受控状态；状态上要覆盖 loading、error、empty、disabled、readonly 等场景；扩展上用组合和 slot 避免把业务 if else 堆进组件。最后补样式隔离、可访问性、测试、文档和版本兼容。组件粒度不是越小越好，而是复用收益要大于理解和维护成本。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先判断是否应该抽象

看到相似 UI 不等于必须抽组件。只有职责稳定、重复出现、变化轴清楚、调用方能用统一 API 表达差异时，抽象才有收益。

02

职责边界决定可维护性

组件内应该放通用展示、交互和可复用逻辑；业务接口、权限判断、路由跳转、埋点和具体文案映射通常留在页面或业务容器层。边界不清会让组件越来越难复用。

03

API 要少而稳定

props 负责输入，events 负责向外报告，slots 负责结构扩展，expose/ref 只暴露必要命令式能力。命名要表达语义而不是内部实现，默认值要让简单场景开箱即用。

04

状态归属要明确

表单值、展开状态、选中状态可以受控、非受控或混合，但必须有清晰规则。loading、error、empty、disabled、readonly、skeleton 和重试都要有一致展示，否则组件只在理想状态可用。

05

扩展靠组合而不是堆参数

一两个稳定开关可以用 prop，大块自定义内容更适合 slot/render prop/children。参数过多会变成隐形 DSL，调用方难理解，维护方也难保证组合行为。

06

补齐工程质量

组件要考虑键盘操作、aria、焦点管理、响应式布局、主题 token、样式隔离、单元测试、交互测试和文档示例。公共组件还要关注 breaking change 和迁移成本。

03

易错点

  • 只回答 props 传参和 emit 通信，没有讨论职责边界、状态归属和扩展点。
  • 把业务接口、登录态、路由跳转写进通用组件，导致组件复用时被业务绑死。
  • 为了灵活加几十个 prop，最后组合行为不可预测，调用方也不知道该怎么配。
  • 只考虑正常态，遗漏 loading、error、empty、disabled、键盘操作和焦点管理。
04

面试官追问

组件粒度是不是越小越好？

不是。粒度太大复用差，粒度太小调用成本高。判断标准是职责是否单一、变化轴是否清楚、组合后是否比复制更容易维护。

什么时候用 prop，什么时候用 slot？

稳定的小差异用 prop，例如 size、disabled、variant。结构差异或业务内容较大时用 slot，避免组件内部堆复杂条件分支。

受控和非受控怎么选？

需要外部统一状态、表单联动或可回放时用受控；简单局部交互可非受控。公共组件最好支持明确的受控契约，并避免两套状态互相覆盖。

公共组件如何避免破坏调用方？

保持 API 语义稳定，新增能力优先向后兼容；删除或改名要有 deprecate、迁移文档和版本策略，测试覆盖关键交互。