Why Proto UI
它解决什么问题，未来会先在哪些场景中变得有价值，以及当前处于什么阶段
这篇文章的目的
Section titled “这篇文章的目的”这篇文章不打算完整介绍 Proto UI 的理论，而是回答一个更实际的问题：
你的问题，是否值得开始关注 Proto UI？
以及：
如果值得，它会先在哪些地方对你产生价值？
一个你可能已经习惯，但代价很高的现象
Section titled “一个你可能已经习惯，但代价很高的现象”很多团队的技术栈，并不是“统一”的。
你可能同时在面对：
- 一些稳定运行的旧系统（Vue 2 / 旧版 React）
- 新项目（Vue 3 / React 18）
- 一些受限环境（小程序、Tauri、嵌入式 WebView）
- 甚至未来要接入的新宿主
这些系统本身未必有问题，它们的问题是：彼此之间很难共享组件能力。
通常，事情会从一个很普通的需求开始：
“我们希望不同项目里的组件体验更统一一些。”
比如：
- 更好的可访问性（ARIA）
- 更一致的键盘交互
- 更规范的状态与反馈
- 更少的行为分叉
然后你会发现：
- 最成熟的组件实现，通常集中在少数主流生态中
- 其他技术栈，要么没有成熟方案，要么质量参差不齐
- 同一个组件能力，往往需要在不同宿主中分别补齐
于是你开始：
- 在不同平台里，各自实现一遍类似的组件
- 或者为某个宿主降级设计
- 或者放弃某些本来应该具备的交互能力
一开始，这只是“多写一点代码”。
但随着宿主、组件和设计语言一起增加，成本会逐渐变成另一种形状：
你在为同一类交互能力，持续支付多份实现与维护成本。
这不是某个框架的问题
Section titled “这不是某个框架的问题”类似的问题，会在不同生态里反复出现：
- 在 Web 中，成熟组件能力常常绑定在特定框架生态中
- 在小程序或受限环境中，生态并不完整，很多能力需要重新补齐
- 在原生 GUI 或游戏 UI 场景中，基础控件存在，但高质量交互往往仍要自己实现
- 当设计系统第一次登陆一个新技术栈时，团队通常不得不重新面对一遍这些问题
这些例子表面不同，但共享一个结构：
交互能力，通常绑定在具体实现与具体宿主中。
这意味着：
- 能力难以直接复用
- 维护范围会随着宿主数量不断扩张
- 组件库与设计系统的扩展，容易变成“框架 × 组件 × 设计语言”的重复劳动
为什么现有方案没有彻底解决这个问题？
Section titled “为什么现有方案没有彻底解决这个问题？”设计系统、组件库、Headless UI、跨端框架，都在缓解这些问题。
但它们通常有一个共同边界：
复用往往仍然发生在实现层，而不是交互语义层。
你可以共享的，常常是：
- 样式
- 结构
- 一部分 API 习惯
但真正最难稳定复用的，往往是：
- 状态流转
- 事件语义
- 键盘与可访问性行为
- 不同宿主中的一致反馈
于是重复依然存在，只是换了一种形式。
Proto UI 的切入点
Section titled “Proto UI 的切入点”Proto UI 试图把组件拆成两层：
- Prototype：描述组件的交互语义
- Adapter：将这些语义映射到具体宿主中
它的目标不是抹平所有差异，而是：
让可以复用的交互定义只写一次，把宿主差异尽量收敛在适配层。
这意味着，Proto UI 关注的不是“某个框架里的一个组件怎么实现”，而是：
同一类组件行为，能否成为跨宿主共享的定义。
你在首页 Demo 中看到的，不只是“切换框架”，而是：
同一份交互定义，被不同宿主解释。
Proto UI 未来会先在哪些地方变得有价值？
Section titled “Proto UI 未来会先在哪些地方变得有价值？”Proto UI 的价值，不会先体现在“全面替代现有生态”。
它更可能先体现在下面这些场景：
1. 生态缺口的快速补齐
Section titled “1. 生态缺口的快速补齐”当某个宿主缺少成熟组件实现，而其他生态已经有较成熟的组件设计时，Proto UI 可以更快补上这部分空缺。
这使它天然适合作为一种兜底方案：
- 不是要求所有人先选 Proto UI
- 而是在现有生态覆盖不到的时候，提供更快的补齐路径
2. 多宿主组件库的扩展成本控制
Section titled “2. 多宿主组件库的扩展成本控制”对于传统组件库来说，支持更多宿主，通常意味着更多实现份数。
而在 Proto UI 中，随着 Prototype 与 Adapter 的增长，扩展成本更接近线性，而覆盖面更接近乘积增长。
也就是说：
新增一个组件，或新增一个宿主，不必把已有工作按笛卡尔积重做。
这会先影响 Proto UI 自身的原型库扩展效率，也会逐步影响基于 Proto UI 构建的组件库与设计系统。
3. 设计系统的渐进式跨端一致
Section titled “3. 设计系统的渐进式跨端一致”Proto UI 不要求你一次性迁移整个项目。
它可以以组件为单位引入，与旧实现并存，并逐步替换。
这意味着：
- 你可以先在新组件中使用 Proto UI
- 也可以在一部分高价值组件上先试用
- 已引入的 Proto UI 组件，可以自然获得跨宿主一致的交互定义
- 后续若需要扩展到更多宿主，不必再为这些组件重新维护多套行为实现
它解决的不是“今天立刻救急”，而是：
从现在开始，阻止下一批新组件继续走向重复实现。
但这不是免费的
Section titled “但这不是免费的”引入 Proto UI，本质上是在交换一类成本。
你减少的是：
- 长期重复实现与重复维护的成本
- 多宿主之间行为逐渐分叉的成本
- 组件库规模增长后，复杂度按乘积膨胀的风险
你引入的是：
- 一层额外抽象（Prototype / Adapter）
- 更复杂的调试路径
- 对组件储备与生态成熟度的依赖
所以 Proto UI 不是一个“立刻见效的救急工具”。
更准确地说：
它适合那些已经知道自己会长期维护组件能力的人。
当前阶段：现在适合期待什么，不适合期待什么？
Section titled “当前阶段：现在适合期待什么，不适合期待什么？”Proto UI 目前仍然处于发布初期。
这意味着：
- 方向已经明确
- 核心能力已经成形
- 但组件储备、宿主覆盖与自动化链路仍在持续补齐
保守估计，在接下来的几个月里，Proto UI 会优先补足：
- 更扎实的基础交互能力
- 更可直接消费的组件储备
- 更顺滑的多组件库产出流程
因此，现在更适合把 Proto UI 看成一个值得关注、值得评估方向的项目，而不是一个已经完成生态铺设的成熟方案。
如果你当前需要的是：
- 完整而成熟的海量组件覆盖
- 对所有宿主都高度稳定的生产级生态
- 马上替代主流框架内成熟组件库
那么现在可能还不是最合适的时机。
但如果你关心的是：
- 多宿主组件能力的长期维护方式
- 生态缺口如何更快补齐
- 设计系统如何减少重复实现
- 一个组件库如何在未来扩展更多宿主而不线性爆炸
那么现在已经是了解 Proto UI 的合适时机。
什么时候值得开始关注它？
Section titled “什么时候值得开始关注它？”- 你需要在多个宿主中维持较一致的交互体验
- 你正在构建组件平台、设计系统或长期维护的组件库
- 你已经意识到重复实现的成本会持续累积
- 你所在的技术栈经常遇到生态覆盖不完整的问题
什么时候它暂时不适合你？
Section titled “什么时候它暂时不适合你？”- 你只在单一框架中开发组件
- 项目周期较短，不打算长期维护这套组件能力
- 你当前更需要成熟生态的现成供给，而不是新的抽象层
- 你不希望承担发布早期项目可能存在的能力边界与演进成本
如果你确认这类问题与你相关，可以继续了解：
如果你更关心完整理论：