功能对等MS Word Parity是文档编辑器领域最容易被低估的词。尤其当它和“网页”以及“协作”叠在一起时这三个词几乎等于一个大型系统工程的目录排版引擎、文档格式解析、实时同步、冲突解决、权限管理、历史版本、导出兼容性……任何一个环节出问题用户都会直接说“不如 Word”。最近在 Hacker News 上有一个项目引发了讨论Collab Word in Web一个目标是接近 MS Word 功能对等的网页端协作 Docx 编辑器。这类项目的价值不在于“又一个富文本编辑器”而在于它选择了一条最难的路——把用户熟悉的 .docx 文件直接在浏览器里编辑并且支持多人协同。这篇博客不打算只复述项目介绍而是想回答几个更实际的问题这类编辑器真正难在什么地方有哪些主流的实现路径如果你要在自己的产品里做类似功能应该怎么设计、怎么避免踩坑文章会给出架构思路、核心代码示例、验证方法和排错清单希望帮你建立一套完整的判断框架。1. 网页版 Docx 编辑器到底难在哪很多人第一次接触网页文档编辑时会觉得“不就是把 textarea 换成一个富文本编辑器吗”。真正动手后才会发现问题远不止输入框。第一层是渲染。浏览器天然支持 HTML但 Word 的排版规则和 HTML/CSS 的排版规则并不等价。Word 用的是基于页面流flow的文档模型有节、页、段落、制表位、分页符、页眉页脚、脚注尾注等概念HTML 是流式布局默认没有“页”的概念。你要把一个 docx 里的复杂排版在浏览器里还原出来不是简单解压 XML 再转 HTML 就能做到的。第二层是格式保真。用户对一个文档编辑器最直接的信任来自于“我在网页里改完下载下来用 Word 打开看起来一模一样”。但 docx 的后缀名虽然叫 docx本质是一个 zip 压缩包里面是几十个 XML 文件外加资源目录。任何一处 XML 结构转换处理不好都会出现字体丢失、表格错位、图片偏移、批注丢失等问题。第三层是协作。多人同时编辑一个文档要解决的核心问题是两个人同时改同一段文字以谁的为准如果只是“后保存的人覆盖先保存的人”那叫互斥锁不叫协同编辑。真正的协同需要操作级同步也就是每个用户的每一次输入、删除、格式化都作为操作同步给其他人并且所有客户端最终收敛到同一个文档状态。第四层是性能。一个几百页带图片、目录、交叉引用的 Word 文档在网页端要做到输入不卡顿、滚动不闪烁、协同光标不漂移这对前端渲染方案和数据结构设计的要求非常高。很多项目能做到“能编辑”但做不到“能用”。所以判断一个网页版 Word 编辑器项目不能只看演示视频要看它在边界条件下的表现中文排版是否正常、表格嵌套是否准确、批注能不能导出、多人同时操作后文档是否一致。这些才是真正的技术分水岭。从项目标题看Collab Word in Web 用了 “Near MS Word Parity” 而不是 “Full Parity”这是一个很务实的定位。完整对等几乎是不可能的Word 有三十多年的历史宏、域、审阅、邮件合并、复杂目录这些功能Web 端想要全部实现工程量接近重做一个 Word。“Near” 的意思是覆盖 80% 用户日常使用的核心功能让绝大多数场景下体验接近桌面版。2. 核心概念Docx、CRDT、功能对等在继续分析架构之前先厘清三个核心概念。这些术语会反复出现搞清楚它们你才能理解后续的设计选择。2.1 Docx 不是“一种文件格式”Docx 是 Office Open XML 标准的一部分本质上是一个 zip 压缩包。你可以把任意一个 .docx 文件改成 .zip 再解压会看到类似下面的结构. ├── docProps/ │ ├── app.xml │ └── core.xml ├── word/ │ ├── document.xml │ ├── styles.xml │ ├── fontTable.xml │ ├── media/ │ └── theme/ └── [Content_Types].xml其中word/document.xml是文档正文里面全是w:p段落、w:r文本片段、w:t具体文字这样的 XML 标签。这意味着所有网页版 Docx 编辑器本质上都逃不开“XML 转内部数据结构再转回 XML”的转换过程。转换过程会丢失信息这是格式保真问题的根源。比如某些 Word 特有的属性在中间数据结构里没有对应字段导出时只能忽略。所以做文档编辑器不只是做编辑更是在做格式转换工程。2.2 协同编辑OT 与 CRDT多人协同编辑主流有两种技术路线OTOperational Transformation操作转换和 CRDTConflict-free Replicated Data Type无冲突复制数据类型。OT 的核心思路是每个操作都带一个位置偏移服务端收到并发操作后通过转换算法调整操作的位置使其在所有人那里都产生相同结果。Google Docs 早期用的就是 OT 思路。OT 的优点是实现相对直观、文档结构可控但算法本身很复杂尤其是在嵌套结构上。CRDT 的核心思路是每个字符、每个节点都有一个全局唯一的 ID操作不需要转换因为数据结构本身保证了不同顺序的并发操作最终会收敛到同一个状态。简单理解OT 是“出现冲突后调整操作顺序”CRDT 是“从设计上就让冲突不可能发生”。网页协作编辑器领域Yjs 是目前最主流的 CRDT 库之一。它的优势在于不需要中心化服务器做操作转换可以通过 WebSocket 做点对点同步自带 Undo/Redo 管理生态里有和 ProseMirror、Slate 等编辑器内核的绑定。2.3 “功能对等”意味着什么“Near MS Word Parity” 通常包含几个层次编辑能力输入、删除、复制粘贴、撤销重做、查找替换。格式能力字体、字号、加粗、斜体、下划线、颜色、对齐、列表、表格、图片。布局能力页边距、纸张方向、分页、页眉页脚。高级协作能力光标共享、批注、版本历史。兼容能力导出的 docx 在 Word/WPS/Google Docs 中打开结果一致。对一个创业团队或开源项目来说前四层已经足够做出一个“可用”的产品。第五层是持续迭代的目标。判断一个项目处于哪个阶段就用这个清单去核对。3. 网页版 Word 编辑器的三条技术路径如果你想在自己的项目里做网页版文档编辑目前有三条主流路径。它们的成本、效果和维护难度差异很大。3.1 纯前端富文本 Docx 转换层这是最“轻”的路线选一个前端编辑器内核比如 ProseMirror、Slate、TipTap通过 mammoth.js 或 docx-preview 这类库把 docx 转成 HTML 或编辑器内部 JSON编辑完成后再用 docx 库生成新的 docx 文件。优点是开发速度快、完全可控、不需要部署重量级服务。缺点是格式保真度有限复杂文档转换时会丢样式只能靠不断修转换逻辑补丁式解决。如果只是做在线预览、轻量编辑、简历上传后简单修改这条路线是最合适的。3.2 集成开源 Office 套件代表是 OnlyOffice 和 LibreOffice Online。它们本身就是完整的 Office 办公套件通过 Docker 部署一套服务前端通过 API 嵌入文档编辑器。优点是格式兼容性极高几乎开箱即用自带协同、权限、版本管理。缺点是部署重量级、资源占用大、二次开发复杂而且不等于你拥有了文档内核的掌控权。如果要做企业网盘、协同办公平台这类完整产品且团队人力有限直接集成是更务实的选择。3.3 自研编辑器内核 CRDT 协同层这是 Collab Word in Web 这类项目会走的路线。选择优秀的编辑器内核在上面叠加 CRDT 同步层再写好 Docx 的导入导出转换器。优点是可以完全掌控编辑体验、深度优化格式转换、按需裁剪功能。缺点是工程量大、调试难度高尤其表格嵌套、分页符、批注这类细节很容易消耗大量时间。如果目标是做差异化产品、探索新的文档交互形式这条路线值得投入。三者的关系可以用一个简单类比第一条路是建一个预制板房快但改造空间小第二条路是买一栋精装写字楼质量高但你想换户型很难第三条路是自建楼前期成本最高但每一层都能按自己的需求设计。4. Collab Word 类项目的架构选型基于 Collab Word in Web 的题目以及目前主流 Web 协作文档工程实践可以从架构层面拆解出四个核心模块编辑器内核、协同同步层、Docx 导入导出服务和存储封装。下图是整体数据流向的文字描述浏览器 A ──► 编辑器内核 ──► Yjs 文档 ──► WebSocket ──► 服务端 浏览器 B ──► 编辑器内核 ──► Yjs 文档 ────┘ │ ▼ 文件存储 版本记录4.1 编辑器内核编辑器内核负责把用户输入变成可操作的结构化数据。现在主流选择是 ProseMirror因为它的文档模型是树状结构支持嵌套节点并且有成熟的协同编辑绑定 y-prosemirror。Slate 也很流行尤其在表格等复杂场景下更加灵活但协同绑定需要更多自己封装。关键评估点不是“哪个库更流行”而是文档模型能不能表达 Word 的段落、样式、表格、图片、批注。序列化为 JSON/HTML 后是否能完整反映 docx 的层级结构。是否支持版本历史所需的“记录每一次变更”。4.2 协同同步层协同层推荐直接用 Yjs。它解决了冲突收敛问题自带的 y-websocket 可以快速搭一个同步服务y-indexeddb 可以把文档缓存在浏览器本地。这样即使断网用户也能继续编辑网络恢复后自动合并。这里要特别注意一个设计决策**协同状态和文件存储状态应该是两套东西。**协同编辑时通过 Yjs 同步的是操作日志和 CRDT 状态服务端定时把整个文档导出成 docx 存入对象存储。不要试图让每个操作都实时写一份完整的 docx那样性能和 IO 成本都扛不住。4.3 Docx 导入导出服务导入导出建议放在服务端做而不是前端。前端负责把 docx 转成编辑器 JSON但只用于“预览和编辑”。真正的重转换应该让 Node.js 服务完成因为前端无法处理大文件也无法保证所有客户端环境一致。导入时前端上传文件服务端解析出 JSON 返回导出时前端把当前编辑状态提交服务端服务端生成 docx 下载。转换链路的两个核心库解析 docx用 JSZip 解压后读取word/document.xml再通过自研映射把 WordprocessingML 转成编辑器 JSON。生成 docx把编辑器 JSON 写成document.xml再通过 JSZip 打包成 zip最后名称改为 .docx。4.4 存储与同步的取舍最常见的错误是把 CRDT 的每次操作都直接写入数据库。CRDT 数据通常是一棵比较大的结构频繁写入会导致数据库压力大、文档打开慢。更稳妥的做法是操作同步走 WebSocket 内存态客户端用 IndexedDB 缓存。服务端定时比如每 30 秒或文档停止变更后 5 秒将 Yjs 文档二进制快照写入对象存储。每次快照生成一个版本号支持历史版本回滚。5. 核心流程拆解从打开文件到多人协作下面把整个流程拆成四步。每一步都说明两个问题这一阶段在做什么以及容易出错的点。5.1 文件导入与解析用户上传 docx 后第一件事是把它解析成编辑器能识别的数据结构。这一步最容易出错的不是解析代码本身而是“解析策略”。Word 文档里存在大量重复、冗余的 XML 标签直接转换会产生很多无意义的中间节点。比如一个文本片段可能被拆分成多个w:r节点如果逐个映射编辑器里会多出大量空的样式标记。推荐策略是先做节点合并再按段落维度提取样式维度最后生成编辑器 JSON。这样既保证显示正确又减少后续编辑时产生的协同操作数量。5.2 协同连接与会话建立当多个用户打开同一个文档时服务端需要创建或加入一个协同会话。基于 Yjs 的实现模式是每个文档对应一个 Y.Doc 实例。服务端维护一个 RoomRoom 里保存 Yjs 文档状态。新用户通过 WebSocket 连接后服务端把当前文档的二进制状态同步给新用户。之后用户的每次操作都会以 Update 的形式广播给房间内其他用户。这里的关键设计是权限校验。不要只靠 WebSocket URL 里的房间号区分权限所有加入连接的请求都必须先在 HTTP 层完成身份认证拿到合法 token 才能建立 WebSocket 连接。否则任意拿到 Room 编号的人都能打开你的文档。5.3 编辑与实时同步用户在编辑器里输入时ProseMirror 产生一个 StepYjs 通过专业绑定把 Step 转成 CRDT 操作通过 WebSocket 广播。其他客户端收到操作后在自己本地的 Yjs 文档上应用再由 ProseMirror 渲染出来。这个过程中最容易踩的坑是中文输入法。中文输入时浏览器会先进入 composition 状态如果在这个状态下同步操作会出现输入一半的状态被打断、候选词错乱、文字重复等问题。正确做法是在 compositionstart 到 compositionend 期间暂停协同操作同步等输入法确认后再发送。很多网页编辑器在中文环境下表现怪异基本都是这里没处理好。5.4 导出 Docx 与下载导出阶段是把编辑器 JSON 还原成 WordprocessingML 的过程。这个阶段的坑比导入更大。推荐的工程方法是一套“双向映射测试”准备一批覆盖常见排版场景的 docx 样本A 转为 JSON 再转回 docx用 Word 打开和原文件做视觉对比B 在编辑器里造出不同的格式组合导出的 docx 用 Word 打开检查。这个测试集合要随着功能迭代持续扩大才能真正守住格式兼容底线。如果你不想完全自研转换器可以使用html-docx-js、docx这类库快速生成简单文档但复杂排版仍然需要自己写映射逻辑。6. 完整示例代码实现为了让设计落地这里给出一组基于 Node.js 的最小示例。代码可以帮你验证思路也可以作为项目的起点。6.1 环境准备建议环境Node.js 20 或更高版本。npm 包管理器代码会用 ES Module 写法。一个现代浏览器Chrome 或 Edge。需要安装的依赖npm init -y npm install yjs y-websocket jszip以下示例以演示通用思路为主版本以实际项目为准。6.2 示例一解析 Docx 并提取正文文本这个示例演示了 docx 解析的第一层——通过 JSZip 解压并读取word/document.xml再提取纯文本。实际项目里你会在这里替换成完整的 XML 转 JSON 逻辑。// 文件路径parse-docx.mjs import JSZip from jszip; import fs from node:fs/promises; async function parseDocx(filePath) { const data await fs.readFile(filePath); const zip await JSZip.loadAsync(data); const documentXml await zip.file(word/document.xml) .async(string); const text documentXml // 每个段落标签转换为换行 .replace(/w:p[ ]/g, \n) // 去掉所有 XML 标签 .replace(/[^]/g, ) // 还原常用 XML 转义 .replace(/amp;/g, ) .replace(/lt;/g, ) .replace(/gt;/g, ) .replace(/quot;/g, ) .replace(/apos;/g, ); return text .split(\n) .map(line line.trim()) .filter(line line.length 0); } const lines await parseDocx(./sample.docx); console.log(lines);运行方式node parse-docx.mjs这段代码虽然简单但要理解它的意义word/document.xml里的标签层次非常深示例用正则提取纯文本只是演示“文件结构”。真实场景中你需要用 XML DOM 解析器遍历节点保留每个段落的样式、字体、大小等信息而不是简单去标签。6.3 示例二用 Yjs 创建协同文档这个示例演示 Yjs 的核心用法创建一个 Y.Doc往一个名为 content 的共享文本类型里写入内容并监听更新事件。// 文件路径yjs-basic.mjs import * as Y from yjs; import { getPersistence } from y-websocket; const ydoc new Y.Doc(); const ytext ydoc.getText(content); // 模拟用户 A 写入内容 ytext.insert(0, Hello, Collab Word in Web!); // 监听更新更新是二进制格式可以广播或持久化 ydoc.on(update, (update, origin) { console.log(收到一次更新来源, origin || local); console.log(当前内容, ytext.toString()); }); // 模拟用户 B 在另一台设备上应用更新 const updateBytes Y.encodeStateAsUpdate(ydoc); const ydoc2 new Y.Doc(); Y.applyUpdate(ydoc2, updateBytes); console.log(用户 B 打开后的内容, ydoc2.getText(content).toString()); // 在用户 B 追加上一段 ydoc2.getText(content).insert(31, Welcome!); console.log(用户 A 最终内容, ytext.toString());运行方式node yjs-basic.mjs这里的关键点是update事件和applyUpdate。协同同步的本质就是把本地产生的 update 发给别人把别人发来的 update 应用到本地。你不需要自己处理冲突CRDT 已经保证了最终一致性。示例里用编码快照模拟了“新用户打开文档”的过程真实项目中这个动作发生在 WebSocket 连接建立时。6.4 示例三通过 WebSocket 同步更新y-websocket 是 Yjs 官方提供的 WebSocket 同步方案可以快速跑通多人协同。服务端代码非常简单// 文件路径server.mjs import { WebSocketServer } from ws; import { setupWSConnection } from y-websocket/bin/utils; const port 1234; const wss new WebSocketServer({ port }); wss.on(connection, (ws, req) { // 真实项目中这里需要插入用户认证逻辑 setupWSConnection(ws, req); }); console.log(Yjs WebSocket 协同服务已启动ws://localhost:${port});运行方式node server.mjs前端配合时使用 Yjs 官方提供的y-websocket客户端// 文件路径client.mjs import * as Y from yjs; import { WebsocketProvider } from y-websocket; const ydoc new Y.Doc(); const provider new WebsocketProvider( ws://localhost:1234, my-document-room, ydoc ); provider.on(status, event { console.log(协同连接状态, event.status); }); const ytext ydoc.getText(content); ytext.observe(() { console.log(最新内容, ytext.toString()); });这个示例体现了多用户协作的最小闭环第一个用户连接 1234 端口第二个用户连上同一个房间两个人对同一个 Y.Doc 的操作会互相同步。要注意的是示例没有做鉴权和 Room 隔离的细化控制只能用于本地实验不能直接部署到公网。6.5 示例四导出 JSON 为简单 Docx最后给一个生成 docx 的示例用最简方式生成一个合法的 docx 文件。// 文件路径export-docx.mjs import JSZip from jszip; import fs from node:fs/promises; async function exportSimpleDocx(content, outputPath) { const zip new JSZip(); // 最简的 document.xml const documentXml ?xml version1.0 encodingUTF-8 standaloneyes? w:document xmlns:whttp://schemas.openxmlformats.org/wordprocessingml/2006/main w:body w:p w:r w:t xml:spacepreserve${content}/w:t /w:r /w:p /w:body /w:document; zip.file(word/document.xml, documentXml); // 必须包含的最小元数据文件 zip.file([Content_Types].xml, ?xml version1.0 encodingUTF-8? Types xmlnshttp://schemas.openxmlformats.org/package/2006/content-types Default Extensionrels ContentTypeapplication/vnd.openxmlformats-package.relationshipsxml/ Default Extensionxml ContentTypeapplication/xml/ Override PartName/word/document.xml ContentTypeapplication/vnd.openxmlformats-officedocument.wordprocessingml.document.mainxml/ /Types); zip.file(_rels/.rels, ?xml version1.0 encodingUTF-8? Relationships xmlnshttp://schemas.openxmlformats.org/package/2006/relationships Relationship IdrId1 Typehttp://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument Targetword/document.xml/ /Relationships); const buffer await zip.generateAsync({ type: nodebuffer, compression: DEFLATE, }); await fs.writeFile(outputPath, buffer); console.log(已生成, outputPath); } await exportSimpleDocx(Hello from Collab Word in Web!, output.docx);运行方式node export-docx.mjs这个示例可以称得上是“手写 docx”的入门模板。它能生成一个 Word 能打开的合法文件说明 docx 的最小结构其实不复杂。但真实项目里你需要生成非常复杂的 XML 结构包含样式定义、主题、字体替换关系等这时通常要引入成熟的生成库而不是自己去拼接字符串。7. 运行结果与效果验证把上面几个示例串起来你可以在本地跑通一条最小链路启动协同服务node server.mjs看到端口监听日志。启动两个客户端分别运行node client.mjs在第一个客户端里对 ytext 做插入观察第二个客户端的监听回调确认内容同步。用export-docx.mjs生成 output.docx用 Word 或 WPS 打开确认文件可以正常显示。用parse-docx.mjs解析一个包含中文和英文的 docx确认提取后的文本没有乱码。如果任何一步失败按下面的顺序排查第一步检查 Node.js 版本和依赖安装大多数模块问题出在 CommonJS 与 ESM 混用上。第二步检查 WebSocket 地址浏览器客户端如果跑在 HTTPS 页面里默认会拒绝 HTTP 的 WebSocket 连接。第三步打开生成的 docx如果 Word 提示“文件已损坏”优先检查 XML 是否缺少命名空间声明。第四步解析中文乱码首先看原文件是不是 docx有些用户上传的其实是 .doc 老格式它和 docx 的解码方式完全不同。8. 常见问题与排查思路问题现象可能原因排查方式解决方案打开 docx 后排版错乱docx 中的结构样式没有完整映射到编辑器 JSON检查 document.xml 中段落和样式标签是否被丢弃完善解析映射表优先覆盖常用段落和表格样式中文输入出现文字重复或乱码输入法 composition 状态下触发了协同操作同步在 compositionstart 到 compositionend 之间暂停 Yjs update 发送参照 y-prosemirror 对 composition 场景的处理方式多人同时编辑后内容不一致服务端没有按房间隔离或更新未正确广播检查所有客户端是否连接同一房间查看服务端日志核对setupWSConnection的文档名参数增加房间级日志导出的 docx 用 Word 打开报错缺少[Content_Types].xml或命名空间不完整用解压工具检查生成文件结构参照标准 OOXML 模板补齐最小文件集大文档编辑越来越卡每次输入都触发全量序列化检查 update 监听里是否做了完整数据导出改为增量操作同步定时快照写入存储WebSocket 频繁断开服务端缺少心跳或超过代理超时时间查看代理层配置和 WebSocket 生命周期日志增加心跳消息调整代理超时设置图片在导入导出后丢失图片资源没有进入 zip 的 media 目录检查解析阶段是否遗漏word/media导入时把图片提取为二进制资源导出时重新写入 zip这些排查点都是实战中高频出现的问题。有些属于格式转换层有些属于协同层有些属于工程配置层。分类清楚以后你的调试效率会高很多。9. 最佳实践与工程建议把这套项目从“能跑”推进到“能上线”需要在工程层面做很多加固。以下是一些关键建议。9.1 转换链路必须自动化测试这是最重要的工程建议。Docx 格式转换是最容易引入回归的地方。每修一个格式 bug都可能影响另一种排版。建议准备一份覆盖以下场景的测试文档集中文正文、中文标题、混合中英文段落。有序列表、无序列表、多级列表。表格合并单元格、嵌套表格、表格边框。图片、超链接、页眉页脚。批注、修订记录。每次提交代码后自动把这些文档跑一遍“导入—导出—对比”的测试。即使不能自动比对像素级差异至少要做到不抛异常、文件结构合法。9.2 协同服务需要独立鉴权Yjs 的 WebSocket 服务不应该暴露在公网。生产环境推荐的做法是前端通过 HTTP API 换取一个短期 tokenWebSocket 连接建立后先校验 token 和房间权限再执行业务逻辑。如果需要更细的控制可以在 WebSocket 服务里做房间级白名单校验。9.3 存储快照与操作日志分离不要把每个 CRDT 操作都写入数据库。合理的方案是操作日志保留在内存或 Redis Stream用于短时间恢复。文档快照定时写入对象存储保留版本号。回滚时通过快照加日志重建文档。这样可以控制存储成本同时保证恢复能力。9.4 注意上传文档的安全隔离用户上传的 docx 文件本质上是一个 zip 包可能包含恶意内容。服务端解析时应该使用纯解析库而不是把文件交给系统命令处理。对解压后的 XML 要做实体扩展防护防止 XML 实体注入攻击。对包含宏的 docm 文件更要做严格的权限隔离甚至直接拒绝处理。9.5 协同体验要在真实网络下测试本地网络环境下协同几乎不会暴露问题但公网环境有延迟、抖动、断线重连。一定要测试以下场景用户断网 30 秒后恢复文档能否自动同步。两个用户同时编辑同一段文字最终是否一致。移动端浏览器进入编辑页面输入法冲突是否正常。这些测试没有工具能完全模拟建议找几个真实用户做小范围灰度测试。10. 总结与后续学习方向网页版协作 Docx 编辑器是一个非常典型的“听着容易、做起来工程量大”的项目。它考验的不是某一个技术点而是格式转换、协同算法、前端性能、服务端高可用等多个体系的综合能力。从 Collab Word in Web 这类项目可以学到的东西不只是它的功能清单而是它暴露出的核心矛盾浏览器不是 Word但用户希望网页文档拥有 Word 的体验。所有技术取舍都是在填补这个鸿沟。如果你想继续深入建议按下面的顺序学习第一熟练 docx 的 OOXML 结构用 JSZip 读写各个 XML 文件。第二理解 ProseMirror 文档模型以及为什么树结构适合富文本。第三掌握 Yjs 的 CRDT 模型理解为什么它不需要 OT 转换。第四研究 y-prosemirror 的绑定代码这是编辑器与协同层的桥梁。第五用真实文档集做格式转换测试把问题清单积累成自己的知识库。在线文档编辑器的市场不会冷却因为协作办公的需求是长期存在的。现在进入这个方向与其说是在学工具不如说是在掌握一套完整的大前端工程方法论。今天文章里给出的架构和示例可以作为你的第一版脚手架。建议收藏备用这个领域值得持续跟踪。