从 ProseMirror 到自研，能替代 WPS/Docs 吗？-字节棱镜 (Byte Prism)

采用 ProseMirror 或 Tiptap 可以作为一条替代路线，帮助团队快速构建编辑器，但是否达到产品级等价，不能仅凭“MIT 开源”或“四个月自研”得出结论。要真正接近 WPS / Google Docs，则要由复杂输入、长文档排版、历史与协作、粘贴与导入导出、格式兼容等验收结果共同决定。

近期热点项目的标题提到，作者自述做了三年 ProseMirror，随后用四个月自研排版引擎，目标是实现 WPS / Google Docs 替代品，并采用 MIT 开源。这是一条值得研究的架构路径，但标题提供的信息仅限于开发经历、目标和许可证，不能替代对具体模块、性能、协作与格式兼容能力的核验。

ProseMirror 先把编辑器的哪些难题拆开了？

ProseMirror 是一个可组合的富文本编辑框架。与功能完备的成品编辑器不同，它将文档模型、编辑状态、变换机制和视图层分别交给不同模块处理。这种拆分方式让开发者可以按产品需求组合节点、命令和插件，不必从头实现光标、输入与文档结构。

第一层是 schema，它规定了文档可以是什么。nodes 定义段落、标题、图片等结构，marks 定义加粗、斜体等行内样式，attributes 保存链接地址、图片尺寸等属性，content 规则则约束一个节点可以包含哪些子节点。节点还能通过 group 区分块级与行内内容。整个文档也是一个 Node，内部内容由 Fragment 组成。

第二层是 state 与 transaction。state 保存当前文档和选区；一次编辑不会直接修改旧文档，而是创建事务，记录变更并生成下一份状态。文档更新遵循不可变原则，新节点替代旧节点，界面再根据新状态重新映射。

第三层是 transform。它提供插入、删除等文档变换能力，并支持对变更进行记录与重放。撤销、重做和协作编辑不能只靠直接修改 DOM 实现，而是建立在这些可追踪的文档变化之上；history、collab 等模块可以接入相应能力。

最后是 view：它把状态映射成可编辑 DOM，并处理点击、键入等交互。节点的 parseDOM 描述外部 HTML 如何解析为模型节点，toDOM 则定义模型节点如何输出到界面。粘贴、导入与渲染因此可以围绕同一份 schema 工作。

因此，一次输入大致会沿着“视图事件 → 命令或插件 → transaction → transform → 新 state → DOM 更新”流转。commands、keymap、inputrules 等模块分别提供命令、快捷键和输入规则，作用于同一份文档模型，而不是各自维护一套文档。

为什么使用 ProseMirror 后，还要自研排版引擎？

浏览器原生 contenteditable 的优势是起步快：开发者不必立即处理文档模型，就能获得基本输入、选区和媒体插入能力。但它很难控制所有输入行为；空节点中的光标定位、第三方输入法、嵌入式浏览器环境，以及浏览器自身的排版限制，都会暴露浏览器编辑能力的边界。

ProseMirror 把文档结构与变化过程收进开发者定义的模型，因而更适合需要精确控制内容语义的产品。代价是 API 更底层：实现一个加粗按钮，就需要理解 state、事务和命令之间的关系。

Tiptap 提供了更友好的封装，例如链式命令、StarterKit 和常用扩展；它还可以接入 React、Vue、Svelte 等技术栈。但它仍以 ProseMirror 为内核；当扩展无法满足需求时，开发者仍可能回到 ProseMirror 的插件与事务层。

完全自研可以取得对输入、选区和排版的控制权，但也意味着项目要重新承担浏览器编辑基础设施中的难题，包括键盘与输入法处理、光标一致性、增量更新和布局稳定性。复杂度并未消失，而是从第三方框架转移到了项目自己的代码和测试体系中。

热点项目作者自述的“三年 ProseMirror、四个月自研”表明，开发者可能已经积累了足够经验，能够判断框架边界并承担重写成本。但这不能证明所有团队都适合复制该路线。具体 API、性能、协作和导入导出能力仍应回到原文与仓库中核验，不能从标题推断。

从编辑器内核走到 WPS/Docs 替代品，哪条路更现实？

落地通常有三条路径：

路径	适合目标	主要代价
基于 ProseMirror 或 Tiptap 补齐产品层	快速验证编辑器产品闭环	接受内核的数据模型和交互边界
保留成熟内核，替换特定模块	输入、排版或某类文档结构存在明确硬约束	需要同时理解框架接口与自研模块
完全自研编辑与排版引擎	控制范围足以形成稳定优势，且有长期维护能力	投入最大，需要覆盖大量浏览器与输入场景