[!info] related notes

• 所属 MOC: frontend-engineering-moc
• 相关概念: ai-engineering-assets-for-frontend-team、design-system-from-tokens-to-product-ui
• 易混淆概念:
• 相关资源:

组件库 vs 物料库

一句话关系

组件库复用基础 UI 能力；物料库复用场景化业务结构。

它们不是同义词，也不是二选一。

组件库

典型内容：

• Button
• Input
• Dialog
• Select
• Table primitive
• Form field
• Tabs
• Tooltip

主要特点：

抽象层较低
业务语义较弱
API 更稳定
跨场景复用范围大

组件库回答：

“这个 UI 基础能力应该怎样稳定实现？”

物料库

典型内容：

• 用户搜索区
• 商品筛选区
• CRUD 表格区块
• 权限配置面板
• Dashboard 卡片组合
• 创建目标表单模块

主要特点：

抽象层更高
业务语义更强
复用粒度更大
通常由多个基础组件组成

物料库回答：

“这一类高频业务场景能不能直接复用一块成熟结构？”

两者如何组合

典型关系：

Design tokens
→ UI primitives
→ Component Library
→ Material / Pattern Library
→ Product Page

例如：

Input + Select + Button + Popover
→ SearchFilterBar material
→ Task List page

所以物料通常建立在组件库之上，而不是替代组件库。

为什么 AI 开发更需要物料库

如果 Agent 只有基础组件：

“做一个任务筛选 Header”
→ 需要重新推断组合结构
→ 容易每次生成不同布局

如果已有物料：

TaskFilterBar
→ 已定义布局、交互、responsive、accessibility
→ Agent 只做配置与少量适配

因此：

组件库减少 UI 原子实现成本，物料库减少业务结构重新设计成本。

什么时候沉淀成组件

更适合组件：

• API 跨多个业务都稳定；
• 视觉/交互属于 design system；
• 业务语义低；
• 需要统一 accessibility / keyboard behavior。

什么时候沉淀成物料

更适合物料：

• 某种页面结构重复出现；
• 内部组合关系稳定；
• 业务语义清楚；
• 重复搭建成本高；
• 允许少量配置而不是完全自由组合。

不要过度物料化

如果一个“物料”：

• 有几十个 boolean；
• 每个业务都要 override 一半结构；
• 内部逻辑高度特例化；

说明抽象边界可能不稳定。

这时更适合：

• 拆回组件；
• 提炼 pattern；
• 或保留项目级实现。

学习检查

1. 组件库与物料库最核心的抽象层级差异是什么？
2. 为什么物料库通常建立在组件库之上？
3. 为什么 AI 页面生成中，物料库比只提供 Button/Input 更能提高一致性？
4. 哪些东西适合进入 design system，哪些更适合项目级 material library？
5. 一个 SearchFilterBar 应该是 component 还是 material？你会根据什么判断？
6. 一个物料出现大量业务特例时，说明什么抽象问题？