很多在线文档编辑器看起来能打开 DOCX，但真正保存一次，格式、表格、图片和修订记录就开始“各自发挥”。

docx-editor 的思路不一样：它把 DOCX 当成需要认真理解的文档格式，直接在浏览器里围绕 OOXML 编辑，再写回 .docx。

这篇不展开源码长拆，只用几分钟讲清楚：它解决的是什么痛点、为什么值得程序员收藏，以及它和普通富文本编辑器到底差在哪。

​

如果你的产品只需要编辑标题、段落和加粗，普通富文本编辑器已经够用。但一旦用户上传真实 Word 文档，事情很快变复杂：

• • 表格可能有嵌套、合并单元格和复杂边框；

• • 图片不只是插在段落里，还可能有浮动位置和文字环绕；

• • 页眉、页脚、样式、编号、批注和修订记录都不能随便丢；

• • 编辑完还得回到一个别人能继续用 Word 打开的 .docx。

难点不是“把文字显示出来”，而是让文档经过编辑后仍然像原来的文档。

这也是 docx-editor 的核心判断：不要把 DOCX 先拍扁成一层 HTML，再祈祷保存时能恢复；应该围绕 OOXML 建立自己的文档模型、布局和序列化链路。

下面保留一张项目原始素材：官方截图（Demo 图），可以看到它不是普通输入框，而是完整的分页文档编辑界面。

一句话理解 docx-editor

它是一个可以嵌进 React 或 Vue 应用里的 WYSIWYG DOCX 编辑器：浏览器负责打开、编辑、修订和保存，核心文档能力围绕 OOXML 保持可回写。

当前仓库提供的方向可以简单看成四层：

这比“找一个 contenteditable，然后把内容存成字符串”要重，但它解决的是更真实的企业文档问题。

它最值得看的 4 个能力

1. DOCX 直接在浏览器里编辑

项目的 React 和 Vue 适配器都围绕 DocxEditor 组件工作：拿到文件的 ArrayBuffer，传给编辑器，用户改完后通过 save() 拿回新的二进制内容。

import { DocxEditor } from '@docx-editor.dev/react';
import '@docx-editor.dev/react/styles.css';

<DocxEditor documentBuffer={buffer} mode="editing" />

官方说明强调，解析、渲染和编辑可以在客户端完成，不需要为“打开一个文档”额外维护服务端转换服务。对在线合同、审批稿、报告模板、知识库文档来说，这个边界很关键。

2. 修订和评论不是外挂功能

审阅场景里，用户最在意的通常不是字体按钮，而是：谁改了什么、能不能接受、能不能拒绝、意见能不能继续讨论。

docx-editor 把 tracked changes 和 threaded comments 放进编辑器本身：修改可以带作者信息，评论可以锚定到文本范围，审阅者可以逐条接受或拒绝。这样做的好处是，审阅状态不会被迫降级成几种颜色或一串旁注。

3. 协作基于 Yjs，而不是“最后一个人覆盖前一个人”

实时协作的关键不只是显示几个头像，而是多人同时编辑时如何合并内容。项目可以把文档绑定到 Yjs，提供共享光标、在线状态、评论同步和冲突合并；开发者再根据部署场景选择 y-webrtc、Partykit 或其他 Yjs provider。

这意味着项目本身没有替你决定所有后端架构，但把“文档内容如何协作”这件事暴露成了可以接入的能力。

4. Agent 可以改文档，但人仍然拥有最后确认权

这是它和普通 DOCX 组件拉开距离的地方。

@docx-editor.dev/agents 提供面向文档的工具桥：Agent 可以对选中文本发表评论、提出 tracked changes、批量处理 LLM 输出；它既可以接在页面里的聊天面板，也可以在服务端用 headless reviewer 处理文档。

最适合落地的方式不是让 AI 直接覆盖原文，而是：

1. 1. 用户选中一段内容；

2. 2. Agent 提出修改或评论；

3. 3. 修改以修订标记呈现；

4. 4. 人类审阅后接受或拒绝。

AI 负责提高修改效率，文档系统负责留下证据，人负责最终判断。 这条链路比“AI 一键重写整篇 Word”更适合合同、方案和内部审批等敏感场景。

它和普通富文本编辑器差在哪里？

这里的重点不是说 docx-editor 能替代所有编辑器，而是：当你的产品真正把 DOCX 当业务资产时，文档格式本身就应该成为架构的一部分。

程序员可以拿它做什么？

• • 在线合同和法务审阅：保留修订、评论、接受/拒绝记录；
• • 报告与方案协作：多人在浏览器里共同修改，不必反复下载上传；
• • 模板填充系统：给 DOCX 模板插入变量，再交给用户审阅；
• • 知识库或企业文档系统：上传后直接编辑，保存时仍然输出标准 DOCX；
• • AI 文档助手：让 Agent 先提出可审阅的修改，而不是无痕覆盖原稿。

也要知道它的边界

它不是“安装一个包就自动拥有完整 Office”的魔法：

• • 浏览器编辑器依赖 DOM，SSR 场景要按文档说明做客户端加载；
• • 复杂 DOCX 的兼容性必须用你自己的真实样本文档验证；
• • 实时协作仍需要选择并配置 Yjs provider；
• • 字体、分页、打印和特殊 OOXML 特性，仍然需要在目标环境里做回归测试；
• • 当前仓库正处于包名/版本迁移阶段，旧教程里可能出现 @eigenpal/*，新 README 使用的是 @docx-editor.dev/*，接入时以当前仓库和文档为准。

所以它更适合“产品确实需要 DOCX 原生编辑”的团队，而不是只想给 Markdown 加一个加粗按钮的项目。

我的判断

docx-editor 真正值得关注的地方，不是又做了一个 Word 工具栏，而是它把 文档格式、浏览器编辑、审阅协作和 Agent 操作 放在了一条可以继续扩展的链路上。

如果你正在做企业文档、合同审阅、模板系统或 AI 文档助手，建议先收藏这个仓库，再拿 3 份真实 DOCX 做一次 round-trip 测试：打开、修改、保存、重新用 Word 打开，重点看表格、图片、页眉页脚和修订记录有没有变形。

后续我会继续拆它的 OOXML 数据流、React/Vue 接入方式，以及 Agent 如何把修改变成可审阅的 tracked changes。

项目地址

https://github.com/eigenpal/docx-editor

阅读原文：点击这里