FAQ

关于 Proto UI 的常见问题与边界说明

这一页回答的是 Proto UI 最常见的一批误解、边界问题与定位问题。

它不替代白皮书正文，也不替代后续的 Specifications 与 Engineering 文档。
如果你已经读完白皮书主线，但仍然对 Proto UI 的定位、边界或生态态度有疑问，这一页会更适合你。

不是。

Proto UI 默认不负责最终 UI 的组合、业务接合和框架级调度，因此它不把自己定义为框架。

更直接地说，框架通常负责组织整套应用或界面的运行方式；
而 Proto UI 更专注于另一层：

把组件的交互语义稳定下来，并把它们带到不同宿主中。

它的主要产物不是“整套 UI”，而是“可被不同宿主承接的组件”。

对使用者来说，这也意味着一件事：
你不需要先全面掌握 Proto UI 的原型体系，才能开始使用 Proto UI 带来的组件成果。

在很多场景下，Proto UI 更像是你当前框架旁边的一层组件基础设施。
它关心的是：

• 更好的组件可用性
• 更高的无障碍支持
• 更一致的跨宿主交互体验
• 把某些原本没有成熟组件生态的宿主也纳入进来

跨端是 Proto UI 的结果之一，但不是它的核心追求。

Proto UI 真正想处理的问题是：

把组件中的交互逻辑，与某个具体技术方案尽量分开。

当这件事成立之后，跨端能力自然会出现。
因为同一份原型可以被翻译到不同宿主中。

但 Proto UI 的关注点并不只是“能不能跨端”，
而是：

• 交互语义能否被稳定描述
• 它能否在不同宿主中被较高保真地还原
• 它能否作为长期可维护的公共基建存在

所以，跨端更像是 Proto UI 的一种外显能力，
而不是 Proto UI 存在的全部理由。

Proto UI 可以作为组件库的底层基础。

用 Proto UI 写出来的组件库，核心价值不只是在某一个框架里可用，
而在于它的组件原型可以被不同宿主承接。

这意味着：

• 一份原型可以对应多个适配结果
• 组件库不必为每个宿主从头重写一遍
• 官方原型和官方适配器的组合，可以天然覆盖 Proto UI 已经登陆过的宿主
• 社区适配器的加入，还可以继续扩展这个范围

所以如果把 Proto UI 放在组件库下面理解，更接近下面这个关系：

Proto UI 不是某一套组件库本身，而是让组件库可以跨宿主生长的基础层。

因为 Proto UI 不打算把自己做成框架。

原型级别的组合，一旦继续往前走，通常就会进入这些问题：

• 最终 UI 如何组织
• 不同原型如何进入业务接合层
• 更复杂场景下的事件与更新如何调度
• 哪些上层能力应该由系统统一接管

这些都已经很接近框架层议题了。
而这些议题本身往往高度依赖宿主，也很难形成一套真正跨平台、长期稳定的统一答案。

Proto UI 在这里的选择是：

专注把组件建模做好，而不试图给出一个大一统的最终框架。

这并不妨碍各个宿主继续在自己擅长的层面发挥。
像 React 这样的系统，本来就有自己成熟的组织与调度方式；Proto UI 没有必要把这些层再重做一遍。

因为这时它已经在承担独立的交互责任。

一旦一个子结构开始拥有自己的 event、props、expose 或 context 关系，
它就不再只是父原型内部的一段静态结构，
而是已经开始以自己的身份与外部交换信息。

如果这时还把它继续留在父原型内部，通常会带来两个问题：

• 父原型的职责开始变得混杂
• 交互责任的边界会越来越不清楚

所以 Proto UI 在这里采取的判断很直接：

独立信息通路一旦成立，就应当对应独立原型。

这不只是为了形式统一，
也是为了让每一个原型都尽量对应一个清晰的交互主体。

因为在这个位置上，Proto UI 选择了更适合人类理解的粒度。

如果从更严格的形式角度看，只要一个子结构激活了任意信息通路，把它拆成独立原型都说得通。
但 feedback 更接近呈现与感知层，它本身未必足够强，未必强到必须单独提升为一个原型。

如果连 feedback-only 的局部都一律强制拆分，
原型系统会更整齐，但也会明显变碎：

• 原型数量更多
• 每个原型的信息量更少
• 阅读和维护时更难形成整体理解

所以 Proto UI 在这里保留了弹性：

feedback-only 可以拆，但不要求必须拆。

这不是因为它不重要，
而是因为 Proto UI 在这里更看重“边界清晰”和“整体可读性”之间的平衡。

取决于宿主之间共享了多少基础。

一个很直观的原则是：

宿主之间共享的能力越多，Proto UI 对一致性的要求就越严格。

例如，同为 Web 宿主时，它们共享的渲染与交互基础很多，
Proto UI 通常会要求它们的适配结果尽可能接近：

• 结构尽可能接近
• 反馈尽可能接近
• 行为尽可能接近

而在跨平台场景中，由于交互媒介、宿主能力、渲染方式本身差异更大，
一致性的重点就不再只是“形式完全一样”，
而会更多落在：

• 核心交互语义是否还在
• 生命周期相对顺序是否保持一致
• 原型允许的差异边界是否被遵守

所以 Proto UI 所说的一致性，并不是所有情况下都要求“长得一样”，
而是要求：

同一个原型在不同宿主中，仍然是同一个交互主体。

因为这两类场景面对的现实条件并不一样。

在 Web 宿主之间，大家共享的基础更多：

• 相近的渲染环境
• 相近的事件体系
• 相近的反馈承接方式
• 相近的结构表达能力

这时 Proto UI 更有条件要求高保真的一致性。

而跨平台场景面对的是另一种问题：
不同媒介本身就可能更适合不同的交互形式。

例如，同一个原型在桌面端和移动端，
未必都应该坚持完全一样的交互外形。
有些在桌面端自然的交互，到移动端继续照搬，反而可能变得不好用。

所以更准确地说，不是“跨平台就天然更宽松”，
而是：

Proto UI 更希望原型在不同交互媒介中，呈现出对该媒介更合适的形态。

这类差异是否允许，不是由宿主随意决定，
而是由原型自身的规则来约束。

支持，也欢迎。

Proto UI 并不打算垄断适配器的编写权。
社区形成更多适配器，本来就是 Proto UI 生态成长的一部分。

官方的态度更接近：

• 欢迎社区适配器出现
• 允许它们采用自己的治理方式
• 在合适的情况下，也可以被合并回官方体系
• 在某些宿主上，官方也可能直接推荐社区维护得更成熟的实现

同时，官方仍然会尽量为重要宿主至少提供一套官方适配器，
作为更中立、更稳定的基础承接方案。

是否进入“官方质量保障范围”，则要看：

• 契约是否清晰
• 维护是否稳定
• 使用与验证是否足够充分

所以社区适配器不是“非官方就不重要”，
也不是“出现了就自动等于官方支持”。

同样是支持，也欢迎。

Proto UI 不打算垄断原型的编写权。
社区完全可以发展自己的原型体系，甚至根据特定领域或业务需要，扩展出自己的原型语法。

当然，这种扩展如果已经偏离了官方原型的公共语义基线，
通常就更适合以独立分支、独立项目或独立 fork 的方式继续发展，
而不一定要并回官方主线。

官方在这里更希望做的是：

维护一份尽可能中立、稳定、适合作为公共基建的原型集合。

这意味着：

• 社区原型可以更激进、更垂直、更贴近特定业务
• 官方原型则更强调公共性、稳定性与长期一致性

和社区适配器一样，
如果某些社区原型在实践中已经足够成熟、稳定，也有可能被官方推荐给开发者使用。
官方维护的是一份公共主轴，而不是原型世界的唯一合法版本。

这份 FAQ 只覆盖目前最常见的一批问题。
如果你还有别的疑问，欢迎继续讨论。

适合长期沉淀、可检索的问题，更适合放到 GitHub Discussions。
适合快速交流、临时追问或发散讨论的问题，则更适合放到 Discord 社群。

如果某个问题反复出现，它也可能会在后续进入 FAQ 或白皮书正文。