为什么这样设计
这一页是可选参考，不是大多数使用者的必读内容。
如果你只是想把表格接进项目，优先看快速开始、迁移、功能页和 API 就够了。只有在你要评估长期采用、做二次封装或统一主题治理时，这一页才值得读。
1. 为什么公开接入入口保持单一
对使用者来说，最重要的是安装、导入和升级路径足够稳定，所以 vtable-guild 对外只保留一个接入入口：
@vtable-guild/vtable-guildcreateVTableGuild作为全局配置入口，用来切预设、语言和全局主题
仓库内部仍然按职责组织源码模块，但这些模块是实现细节，不需要由使用者理解或分别安装。这样做的价值是：
- 安装路径简单，不需要判断该装哪些包
- 类型链更短，主题覆盖和组件类型只围绕一个入口
- 版本心智更清晰，升级时只关注一个包
2. 为什么主题要做成三层
如果主题只有一层，通常会出现两个问题：
- 全局改起来太重，单页不好做例外。
- 单页改起来太散，最后全是业务样式补丁。
vtable-guild 把主题拆成三层，就是为了解决这个问题：
- 预设负责整体视觉基线。
- createVTableGuild 的全局 theme 负责应用级统一覆盖。
- 实例 ui 负责单张表格的局部调整。
这意味着你既能快速接入 antdv 或 element-plus 风格，也能只改一张表的表头、单元格或根容器样式，而不必复制整套主题。
3. 为什么它适合从现有表格迁移
VTable 的思路不是让你重新学习一套完全不同的表格模型，而是把常见能力继续留在 columns 和 props 里：
- 排序、筛选、选择、树形和展开行都通过声明式配置组合。
- 虚拟滚动、列宽拖拽和主题覆盖作为增强能力直接叠加。
- 原本散在业务页面里的很多交互和样式补丁，可以回收到表格本体上。
这也是它适合替换现有业务表格的原因。你迁移的重点更多是确认边界，而不是整页推倒重写。
什么时候值得看这页
下面这些情况再回来看就够了：
- 你在评估是否长期采用 vtable-guild。
- 你要做企业内部二次封装。
- 你要统一多条业务线的表格主题。
- 你想理解为什么 themePreset、theme 和 ui 要分开使用。