富文本编辑器内核：Slate 与 ProseMirror 的文档模型及协同机制
一、contenteditable 的陷阱：为什么富文本编辑器需要自建文档模型
去年我们给一个协作文档产品做内核升级，原方案直接基于 contenteditable，上线三个月 bug 单堆到两百多。最典型的是「换行幽灵」：同样的回车操作，Chrome 产生<div>，Safari 产生<p>，Firefox 产生<br><br>，复制粘贴时还混入 Word 的私有标签。这事我见过太多团队栽进去——以为 contenteditable 是免费午餐，最后全在补 DOM 差异。
contenteditable 的根本问题在于：它让浏览器持有文档真相。HTML DOM 既是数据模型又是渲染层，任何浏览器的解析差异、粘贴脏数据、光标行为不一致，都会直接污染业务数据。你无法保证「同一份文档在不同浏览器里结构一致」，因为真相本就不在你手里。
富文本编辑器要走出这个泥潭，必须自建文档模型。核心思路是「数据与渲染分离」：用一棵自描述的 JSON 树（或不可变结构）作为文档真相，contenteditable 只负责把模型渲染成 DOM 并接收用户输入，任何输入都先转换为模型变换（Transformation），再由模型驱动重渲染。DOM 退化为视图层，不再被信任。
Slate 与 ProseMirror 是这一思路的两个代表实现。Slate 用纯 JSON 树描述文档，所有编辑操作是对 JSON 的不可变变换，状态可回溯、可序列化。ProseMirror 则引入 Schema 约束文档结构，配合 Decoration 做无副作用的临时装饰（如高亮、批注光标），更贴近数据库式的严谨建模。
两者都把「选区」从 DOM Range 中抽离出来，用纯数据结构表达。这样光标的移动、选区的扩展都变成可计算的变换，不再依赖浏览器对 Range 的不一致实现。协同编辑也才有了基础：所有编辑动作都被归约为「对文档模型的一次变换」，可以序列化、传输、回放。
二、文档模型与变换：Slate 的 JSON 树与 ProseMirror 的 Schema
Slate 的文档模型是一棵嵌套 JSON。Document 包含一组 Block 节点，Block 包含 Inline 节点，Inline 包含 Text 节点。每个节点都是普通对象，文本内容存在text字段，样式以bold、italic等标记属性附在 Text 上。这棵树天然可序列化，存数据库、传网络都无需中间格式。
Slate 的编辑操作被归约为「变换」（Transforms）。插入文本、删除节点、设置标记，都对应一个 Transform 函数。变换是纯函数：输入旧文档与参数，输出新文档，旧文档不被修改。这种不可变设计带来三个直接好处：撤销栈天然可建（旧文档还在）、状态可快照、协同时只需传输变换而非整篇文档。
ProseMirror 走得更远。它用 Schema 定义合法的文档结构：哪些节点能嵌套哪些、哪些标记能附着在哪些节点上。任何不在 Schema 内的节点会被拒绝写入模型，从源头杜绝脏数据。文档本身是一棵不可变树，修改通过Node.replace生成新实例，配合 Transaction 记录变更步骤。
ProseMirror 的 Decoration 是另一个精巧设计。它允许在不修改文档模型的前提下，给视图层添加临时标记——比如协同场景下其他用户的光标位置、搜索高亮、拼写检查下划线。这些装饰是「视图态」，不污染真相，退出后文档回到干净状态。Slate 后期也引入了类似的概念，但实现不如 ProseMirror 彻底。
协同编辑的核心难题是「并发修改冲突」。两个用户同时编辑同一处文本，若都基于旧版本做变换，合并时就会互相覆盖。主流解法有两套：OT（Operational Transformation）与 CRDT（Conflict-free Replicated Data Type）。OT 通过变换函数调整并发操作的顺序与位置，保证最终一致；CRDT 则设计数据结构本身具备合并确定性，无需中心化变换。
综上，协同编辑的关键在路径统一：DOM 事件不直接改 DOM，而是先转 Transform、过 Schema、改模型、再渲染；协同端变更也走同一条路径，本地与远端在模型层汇合，DOM 始终是模型的镜像。这样冲突可合并、状态可回溯。
三、生产级编辑器模型实现：变换与选区
下面实现一个轻量编辑器模型，包含文档树、不可变变换、选区表达与基本的 Schema 校验。它不依赖任何框架，可作为理解内核机制的参考。
// 文档模型类型定义 interface TextNode { text: string; bold?: boolean; italic?: boolean; } interface BlockNode { type: 'paragraph' | 'heading'; children: TextNode[]; } interface DocState { blocks: BlockNode[]; } // 选区：纯数据结构，脱离 DOM Range interface Selection { blockIndex: number; offset: number; length: number; } // Schema 约束：定义合法节点与标记 const SCHEMA = { blocks: ['paragraph', 'heading'], marks: ['bold', 'italic'], } as const; export class EditorModel { constructor(private state: DocState) {} // 不可变插入文本：返回新文档，旧文档不动 insertText(sel: Selection, text: string): DocState { const { blockIndex, offset } = sel; const block = this.state.blocks[blockIndex]; if (!block) return this.state; // 越界保护，不抛异常保证编辑不中断 const newBlocks = [...this.state.blocks]; // 深拷贝受影响块，其余块保持引用共享，降低拷贝开销 const newBlock: BlockNode = { ...block, children: [...block.children] }; // 定位到 offset 所在的 Text 节点并切分插入 let acc = 0; for (let i = 0; i < newBlock.children.length; i++) { const t = newBlock.children[i]; if (acc + t.text.length >= offset) { const pos = offset - acc; const before = t.text.slice(0, pos); const after = t.text.slice(pos); // 插入的新文本继承当前节点标记，符合用户对"接着写"的预期 const insertNode: TextNode = { text, ...(t.bold ? { bold: true } : {}), ...(t.italic ? { italic: true } : {}), }; newBlock.children = [ ...newBlock.children.slice(0, i), { ...t, text: before }, insertNode, { ...t, text: after }, ...newBlock.children.slice(i + 1), ]; break; } acc += t.text.length; } newBlocks[blockIndex] = newBlock; return { blocks: newBlocks }; } // 切换标记：加粗/斜体等，作用于选区内所有 Text 节点 toggleMark(sel: Selection, mark: 'bold' | 'italic'): DocState { if (!SCHEMA.marks.includes(mark)) return this.state; // Schema 校验 const block = this.state.blocks[sel.blockIndex]; if (!block) return this.state; const newBlock: BlockNode = { ...block, children: block.children.map((t) => ({ ...t })) }; // 简化实现：对整个块切换，生产实现需精确按 offset 拆分 const anyHas = newBlock.children.some((t) => t[mark]); newBlock.children.forEach((t) => (anyHas ? delete t[mark] : (t[mark] = true))); const newBlocks = [...this.state.blocks]; newBlocks[sel.blockIndex] = newBlock; return { blocks: newBlocks }; } // 生成变更步骤：协同场景下只传 diff，不传整篇 toChangeSteps(prev: DocState): ChangeStep[] { // 简化为按块对比，生产实现可用 Myers diff 做细粒度差异 const steps: ChangeStep[] = []; const maxLen = Math.max(prev.blocks.length, this.state.blocks.length); for (let i = 0; i < maxLen; i++) { if (JSON.stringify(prev.blocks[i]) !== JSON.stringify(this.state.blocks[i])) { steps.push({ type: 'replace', index: i, block: this.state.blocks[i] }); } } return steps; } // 应用远端变更步骤：协同合并的核心入口 applyRemoteStep(step: ChangeStep): DocState { if (step.type === 'replace') { // 越界时自动补位，避免远端块序与本地不一致导致丢失 const newBlocks = [...this.state.blocks]; while (newBlocks.length <= step.index) { newBlocks.push({ type: 'paragraph', children: [] }); } newBlocks[step.index] = step.block; return { blocks: newBlocks }; } return this.state; } // 序列化：模型转 HTML，渲染层负责实际 DOM 操作 toHTML(): string { return this.state.blocks .map((b) => { const tag = b.type === 'heading' ? 'h2' : 'p'; const inner = b.children .map((t) => { let s = escapeHTML(t.text); if (t.bold) s = `<strong>${s}</strong>`; if (t.italic) s = `<em>${s}</em>`; return s; }) .join(''); return `<${tag}>${inner}</${tag}>`; }) .join(''); } } interface ChangeStep { type: 'replace'; index: number; block: BlockNode; } function escapeHTML(s: string): string { return s.replace(/[&<>]/g, (c) => ({ '&': '&', '<': '<', '>': '>' }[c]!)); }关键点有四处。其一，所有变换返回新 DocState，旧 state 不变，撤销栈与快照天然可建。其二，越界访问做兜底返回原状态，不抛异常，保证编辑过程中断不会丢数据。其三，变更步骤只传 diff，协同带宽可控。其四，toHTML 时统一转义，从源头挡掉 XSS。
四、协同的代价：冲突解决与适用边界
自建文档模型不是没有代价。
OT 的实现复杂度远超想象。变换函数必须满足两个数学性质：收敛性（TP1）与意图保持（TP2）。业界能用 OT 跑通协同的团队屈指可数，大多数项目直接接入 Yjs、Automerge 这类成熟库。某团队曾自信手写 OT，上线后偶发「文字被吞」，排查发现是 TP2 不满足，最后还是换成了 Yjs。
CRDT 牺牲了内存与带宽换确定性。Yjs 的 RGA 结构会保留所有插入的元信息（作者 ID、逻辑时钟），文档越大元数据越膨胀，长文档的内存占用可达纯文本的 3 到 5 倍。对超长文档（如十万字以上）需做分片协同，否则内存压力会拖垮浏览器。
Schema 约束是一把双刃剑。它从源头挡住非法结构，但也意味着任何新功能（如嵌套表格、内联代码块）都要先改 Schema。Schema 升级时旧文档可能不兼容，需要写迁移脚本。灵活性与严谨性在这里直接对冲。
性能上，富文本编辑器是 React 等虚拟 DOM 框架的重灾区。一次大范围选区删除会触发整棵文档树重建，若用 React 做渲染，diff 开销会肉眼可见地卡顿。ProseMirror 自己实现了细粒度的视图更新，Slate 早期强依赖 React 导致性能瓶颈，后期才支持按节点级更新。
适用边界：协作文档、知识库、富文本笔记类产品收益最高，这些场景对数据严谨性与协同能力强依赖。轻量输入框、评论区纯文本、表单字段，自建模型是过度工程，直接 textarea 配合简单格式化即可。
结论
富文本编辑器的核心是「自建文档模型 + 不可变变换 + 选区数据化」，协同则依赖 OT 或 CRDT 解决并发冲突。落地建议：第一，绝不信任 contenteditable，DOM 只作视图层，真相在模型。第二，所有编辑操作归约为不可变 Transform，旧状态保留以支持撤销与快照。第三，用 Schema 约束合法结构，从源头挡脏数据，代价是功能扩展需改 Schema。第四，协同优先接入 Yjs 等成熟 CRDT 库，不要手写 OT。第五，长文档做分片协同，控制 CRDT 的元数据膨胀。最终在数据严谨性、协同实时性与性能之间取得平衡。这条路在协作文档场景下能跑通，回报是值得的。
