它是怎么工作的？

用 Prototype + Adapter 理解 Proto UI 的最小工作模型

在上一页中，你已经看到：

同一份组件，在不同宿主中表现一致。

这一页要回答的是：

• 这种事情最基本是怎么做到的？
• Prototype 和 Adapter 分别在做什么？
• 为什么这是理解 Proto UI 的起点？

你可以先用一句话理解 Proto UI：

Prototype + Adapter = 某个宿主里的组件实现

这不是完整理论，但已经足够解释你刚刚看到的 Demo。

在首页 Demo 中，你看到的是：

• 切换不同宿主（React / Vue / Web Components）
• 组件的交互行为保持一致

从这个模型来看，本质上发生的是：

• Prototype 没变
• Adapter 换了

也就是说：

同一份交互定义，被不同宿主重新解释。

Prototype 负责描述：

这个组件应该如何交互。

它关注的是：

• 状态如何变化
• 用户输入如何被处理
• 组件如何反馈

而不是：

• React 怎么写
• Vue 怎么写
• DOM 怎么操作

你可以把它理解为：

Prototype 把组件中与宿主无关的交互部分，单独描述出来。

Adapter 负责回答另一个问题：

这些交互，在这个宿主里要怎么实现？

它决定的是：

• 如何映射到宿主能力
• 组件 API 如何组织
• 哪些能力可以直接承接，哪些需要适配

所以：

• Prototype 定义“要发生什么”
• Adapter 决定“在这里怎么做”

你可以用一个很简单的流程理解它：

1. 选择一个 Prototype（交互定义）
2. 选择一个 Adapter（目标宿主）
3. 组合它们
4. 得到该宿主中的组件实现

这也是为什么：

同一个 Prototype，可以被多个宿主复用。

在这个分层下：

• 交互定义可以独立于具体实现存在
• 同一个 Prototype 可以被多个宿主解释
• Prototype 和 Adapter 可以分别演进

这个模型也有清晰的边界：

• 它不意味着所有宿主天然完全等价
• 它不意味着组件可以零成本迁移
• 它不意味着有 Prototype 就一定有高质量实现

Proto UI 做的事情更接近：

把可复用的部分和必须适配的部分拆开。

而不是消除差异本身。

如果你想继续往下看，更深一层的问题，例如：

• 为什么要这样抽象组件
• 这种抽象的边界在哪里
• 一致性是如何约束出来的

会放到 Whitepaper 中讨论。

如果你想判断它值不值得引入：

• 前往 Why Proto UI

如果你已经想直接开始使用：

• 前往 快速开始

如果你想继续理解它背后的设计原则：

• 前往 Whitepaper