物料体系设计：组件库如何服务低代码平台

结论先行：物料（Material）不等于组件库——组件库只回答"怎么渲染"，物料还要回答"怎么配置、怎么联动、怎么分发"。成熟的物料体系有三个硬指标：元数据协议完备（属性/事件/插槽全覆盖）、可独立版本化、可进入物料市场分发。缺任何一条，组件越多平台越乱。

做低代码平台（Low-Code Platform）的团队常在物料上翻车：组件写了一堆，拖进画布后属性面板却是空白，事件不知道怎么配。问题不在组件本身，而在"组件之上缺少一层机器可读的描述"。本文讲清这层描述怎么设计。

物料与组件库的区别：一份代码，两份描述

打个比方：组件库是"食材"，物料是"带说明书的半成品菜"——说明书告诉设计器这道菜能加什么料（属性）、出锅时触发什么动作（事件）、中间能夹什么馅（插槽）。

因此在工程上，一个标准物料 = 组件实现代码 + 物料描述协议（物料元数据）。组件实现可以来自任何组件库，真正属于低代码平台的是那份元数据——它是属性面板、事件面板、画布嵌套能力的共同数据来源。这份元数据在整机里位居哪一层、与引擎层和编辑器层怎么划界，低代码平台的六层架构给过完整的位置图。

物料元数据协议：属性、事件、插槽

属性面板不该为每个组件手写，而应由元数据驱动生成。一个精简示例：

{
  "componentName": "Input",
  "props": [
    { "name": "placeholder", "title": "占位提示", "setter": "StringSetter" },
    { "name": "disabled", "title": "是否禁用", "setter": "BoolSetter" }
  ],
  "events": ["focus", "blur", "change"],
  "slots": [{ "name": "prefix", "title": "前缀插槽" }]
}

设计要点三条：第一，设置器（Setter）要标准化为有限几种（字符串、布尔、数字、枚举、表达式），属性面板按类型自动选控件；第二，事件清单必须显式声明，事件面板据此生成绑定界面；第三，插槽信息让画布支持嵌套拖拽，缺了它容器组件就是"黑盒"。

三级物料分层

基础物料：按钮、输入框、布局容器等原子组件，来自通用组件库，数量少但复用率极高；
业务物料：登录表单、地址选择器等带业务语义的组合，封装了默认样式与事件逻辑；
区块模板：完整页面片段（如"用户列表页"），本质是一段可导入的 DSL 快照，用于一键起步。

分层的价值是控制复杂度：业务人员主要消费业务物料与模板，不必直接面对几十个原子组件。

版本管理与物料市场

物料必须独立于平台发版：平台 1.0 也要能加载物料 2.3。通行做法是物料按语义化版本（SemVer）独立打包，描述协议自带 version 字段，宿主按兼容区间加载。物料市场（Material Market）则解决分发问题：上传、审核、检索、依赖声明，让第三方也能贡献物料——这是平台生态的起点。

以猫拽低代码（CatPull）为例，其物料库同时接入 UniApp、uni-ui、Element Plus 与 Vant 组件体系，并在元数据中标注适用的目标端，设计器按项目端类型过滤物料列表，从源头避免"把移动端组件拖进桌面项目"这类错配。

建设顺序：从 0 到 1 的 5 步

先定协议再写物料：1）冻结元数据协议 v1；2）改造 10 个高频组件补齐元数据；3）属性面板改为元数据驱动；4）从高频页面中抽离业务物料；5）最后再谈市场与三方共建。顺序颠倒的团队，通常会把协议改到第 4 版才稳定，前面积累的物料全部要返工。

FAQs

Q1：物料协议自研还是参考开源协议？

A：可参考社区成熟物料协议（如阿里 lowcode-engine 规范）降低设计成本；若技术栈差异大（如以 UniApp 为底座跨多端），自研更可控。关键是字段语义清晰、可版本化。

Q2：低代码平台该接入多少物料？

A：基础物料控制在 40~60 个即可覆盖大多数页面，业务物料按场景逐步扩展。物料在精不在多——每个物料都要有完整的属性面板与事件支持，残缺物料反而拉低搭建体验。

Q3：物料如何支持多端？

A：在元数据中声明支持的端（platforms 字段），设计器按当前项目目标端过滤物料；同一物料的实现可按端做条件编译，对外协议保持一致。