ProseMirror 产品开发者：树形文档架构下，你的 Markdown 源码第一次保存就丢了

做 ProseMirror 相关产品三年的开发者在 V2EX 发长文，逐版本阅读了主流 Markdown 转换库的源码，提出一个架构判断：当文档的权威是那棵 JSON 树、Markdown 只是它的一种打印方式时，你写下的那份源码，早在第一次保存时就已经不在了。

他拿最常用的几个实现举例。prosemirror-markdown 1.13.4 把斜体和粗体写死成星号，你写的下划线强调存一次就变了；无序列表默认一律变成星号，你习惯的短横线没了；有序列表会被重新编号，行尾两个空格的换行统一改成反斜杠；遇到它不认识的语法直接报错，默认 schema 里没有表格、脚注、删除线。Tiptap 官方的 @tiptap/markdown 3.30 同样把粗体斜体写死，没有对应渲染器的节点直接输出空字符串，内容就这么静默消失了。社区的 tiptap-markdown 已经停止维护，遇到表达不了的节点输出占位符，表格一有合并单元格就降级成 HTML，列对齐信息也丢了。

作者强调这些不是 bug，是架构必然的结果。打印方式只有一种，所以你写的那份源码，早在第一次保存时就已经不在了。对一个人写笔记可能无所谓，但对三个场景很要命：文档放在 Git 里改一个字 diff 却是满屏格式变化；AI 只改了一段整篇写法却被规范化了；同一份文件还要给 VS Code、静态站点、别的 Markdown 工具用。

他接着测试了 Markdown 语法本身的真实限制。用 micromark 4.0.2 加 GFM 扩展逐条实测：表格单元格里只能放行内内容，放列表或代码块会把表格当场拆坏；行内代码里不能再加粗，链接里不能再套链接；中文标点会让加粗失效——CommonMark 判断星号能否开始或结束强调要看两边是不是标点和空白，中文引号括号是标点后面又紧跟着汉字，规则就判它不成立，英文写作几乎碰不到这个问题，中文写作却天天碰到。

作者的方案是 MSFE（Markdown Source-First Editor），让 Markdown 源码本身成为权威。复杂块用代码围栏装数据，在 MSFE 里渲染成可编辑的多维表格，在 GitHub 或 VS Code 里就是一段代码不会坏也不会丢。协同编辑的是 Markdown 源码本身，一个 Yjs 文本，任何一段文本都是合法的 Markdown，所以不存在结构不合法要删节点的问题。

他用 CodeMirror 6 的装饰和 widget 做所见即所得：标题变大、标记符号藏起来、表格画成表格、公式渲染成公式，可底下的文本一个字都没变。三种视图——文档视图、实时预览、源码视图——是同一个 CodeMirror 实例上的不同呈现，切换时不做任何转换，选区和撤销历史都还在。

性能方面，他给 Lezer 的 Markdown 增量解析加了复用证明，解析器记下哪些区间是原样复用的，编辑器据此跳过没变的部分。1 MiB 文档连续输入 20 次，语法树访问从 107760 降到 1380，少了 98.7%；语法树比较从 153940 降到 660，少了 99.6%。证明不成立的地方退回完整比较，正确性不受影响。

作者明确承认源码优先有代价：每次输入都要更新语法树，文件一大就慢。MSFE 目前还是 alpha，API 还会变。开源部分 MIT 协议，AI 读写文档、待审阅形式显示改动和批注是商业组件。他同时推广 QuireKit 整套编辑器生态，包括基于 ProseMirror 的分页文档编辑器 Classic。

值得注意的边界是：这些性能数据是作者自报的基准测试，代码围栏方案对复杂块的可移植性——即其他 Markdown 工具能否识别和编辑围栏内的结构化数据——并未由第三方验证。作者的核心论证（树形权威导致源码丢失）建立在对具体库版本的源码阅读上，可检查；但替代方案的长期维护成本和生态兼容性仍是开放问题。