为什么关注 Proto UI

一个团队同时维护 React 和 Vue 应用时，修复一次 Switch 的键盘操作、禁用行为或状态通知，可能需要在两套组件中分别完成。以后迁移技术栈，相同的责任又会出现。

值得共同维护的知识，往往就在这些细节里：什么操作应当改变状态、用户必须感知什么、应用应在什么时候收到通知。Proto UI 希望把其中能够跨技术成立的部分保存下来，让后续实现能够复用并检验它们。

成熟组件库已经在缓解这种重复。例如，Headless 组件库会集中维护状态、键盘交互和无障碍处理。如果你的需求已经被所在生态可靠地覆盖，继续使用它们完全合理。Proto UI 进一步探索的是：这些知识能否跨越原有的技术边界，继续被执行和维护。

• 同时维护多个 Web 技术栈。 你希望同一类组件的行为修正能够共享，并在各个应用中验证。
• 长期建设组件库或设计系统。 你希望交互定义能够跨越当前框架的生命周期，逐步积累，而不是随每次迁移重新整理。
• 现有生态缺少某项组件能力。 可以先查看官方原型库和目标 Adapter 是否已经覆盖需求；若未覆盖，仍需投入原型或适配工作。

这些场景说明了复用可能有价值的位置，实际收益取决于组件覆盖、宿主能力和接入成本。新增 Adapter 并不自动让所有 Prototype 可用，每种组合仍需验证。

共享定义有机会减少多份行为实现之间的分叉，但也引入了新的维护责任。排查问题时，你可能需要分辨：交互定义是否完整、Adapter 是否正确承接、应用是否以合适的方式使用了它。

目标 Host 的输入、焦点、渲染和无障碍能力也仍然需要被正确接入。复用定义可以集中一部分工作，无法提前消除所有宿主差异或验证成本。

如果你只需要单一框架中的成熟组件，且现有方案已经满足需求，引入这一层抽象的收益可能有限。即使你有多技术栈需求，也应先核对当前覆盖，再决定投入范围。

比起先决定是否迁移整套组件库，更有用的起点是：

1. 在 UI Library 中选一个与你的业务相关的组件，查看 API 和示例。
2. 按快速开始把它接入一个现有页面。
3. 检查你实际依赖的输入方式、状态通知、样式和无障碍行为；如果计划跨框架使用，在每个目标环境中验证。
4. 记录接入与排错成本，以及能否减少你原本需要重复维护的部分，再决定是否扩大使用。

当前已有 0.2.0 稳定发行的上手路径，项目仍处于 v0 阶段。官网 Demo、仓库开发进展与某个已发布版本的能力可能不同，评估时请以实际安装的版本和目标 Adapter 为准。

接下来阅读它是怎么工作的？，了解 Prototype 与 Adapter 怎样分工。如果你更关心这个方向为何成立、又可能在哪里失败，可以从白皮书序章进入完整论证。