设计理念
这页先解释 xiaoye-components 为什么要收束成“基础层 + 中后台业务增强层”双产品线，而不是继续把所有能力混在同一个包里。
这个项目的目标不是把所有能力都塞进一个入口，而是让基础层保持通用、增强层承接中后台高频闭环，把页面编排和请求链路做顺手、做稳定、做成文档能直接复用的形态。
为什么做这次分层
很多团队在做后台系统时，真正卡住的不是“有没有 Button / Input / Table”，而是下面这些问题：
- 基础组件能单独工作，但放到同一页里以后，请求、筛选、批量动作、详情、编辑开始打架。
- 单个组件 API 看得见，但页面级闭环很难快速拼出来。
- 通用组件和后台专属能力混在一起以后，边界越来越模糊。
这个项目想解决的，就是这些更贴近日常开发的问题。
双产品线各自负责什么
基础层保持中性
xiaoye-components 负责原子组件、通用容器、基础输入、基础数据展示和基础浮层，不再混入过多中后台专属业务语义。
增强层承接页面级闭环
xiaoye-pro-components 负责把 SearchForm / ProTable / RequestForm / CrudPage / DetailPage 这类中后台高频链路做成正式公开 API。
中文优先的示例
文档继续保持中文优先，让团队内部讨论、复制示例和调试页面时不需要额外做术语转换。
双产品线分别适合什么
xiaoye-components- 通用 Vue 3 页面
- 管理台和业务台的基础控件层
- 需要中性基础组件的项目
xiaoye-pro-components- 后台管理系统
- SaaS 管理台
- 中后台业务平台
- 需要快速交付页面闭环的内部工具项目
当前不打算解决什么
- 基础层直接承接大量页面容器和工作流能力
- 低代码设计器或自定义规则 DSL
- BPMN 工作流引擎或后端 SDK
- 把权限、审批、请求系统做成强绑定业务框架
当前边界
如果你的项目核心需求是“一个包里同时承接基础层、增强层、工作流和业务引擎”，那么当前这套分层策略并不打算往那个方向走。
文档写作约定
- 先解释这是基础层还是增强层，再给示例和 API。
- 优先用真实页面语境描述增强件，而不是只写抽象属性名。
- 聚焦当前版本已经稳定可用的能力，不提前承诺未落地的引擎能力。