CRomputer-罗军我最早被多人协作文档合并这件事折磨，是在一次大型投标文件的筹备现场。几十个同事分头写技术方案，最后汇总到我这的时候，光是目录就重排了三遍，页眉页脚在合并后全部错位，有人用的是WPS，有人用的是Office，格式直接互相“打架”。最崩溃的是，有一位同事在最后关头改了正文里的关键条款，但由于合并时版本覆盖，那份修改直接丢了。也就是从那时候起，我开始认真思考：文档合并这件事，不能再靠人工去“拼”，得从系统层面做一个靠得住的企业级文档拆分合并方案。
这篇内容就是我对整套方案的完整复盘，包括技术选型、系统架构、核心实现细节，以及上线后踩过的一堆坑。
1. 多人协作里的“合并灾难”，远比你想的更复杂
在做这套系统之前，我先把企业里文档合并的痛点全部列了一遍。不列不知道，一列吓一跳。很多人以为文档合并嘛，不就是把几个文件拼接起来，可实际上，不同场景下的合并难度差别巨大，带来的影响也完全不是一个量级。
1.1 三种典型合并场景，每一种都是血泪
第一种是章节拆分合并。也是最常见的。一份大文档，比如投标文件、可研报告、验收材料，按章节分给不同的人写，写完再把所有章节合回一个完整文件。这种场景的核心痛点是格式统一：每个人写东西的习惯不一样，有的人喜欢用标题1、标题2这样的内置样式，有的人坚持手动调整字号，有的人喜欢在段前加空格模拟缩进，合并之后，光是把这些乱七八糟的格式统一成一份体面的正式文档，就可能花费半天时间。
第二种是多人并行修改同一份文档。这种更麻烦。几个同事同时打开同一个文件修改，最终保存的时候，后保存的那个人会把先保存的人的内容直接覆盖掉。企业里很多重要文档都是这样丢内容的——不是被删除，而是被覆盖，而且完全无感知，等人发现的时候已经过了好几轮修改，根本无法回溯。这也是最让我揪心的场景：数据丢失的后果往往比格式混乱严重得多。
第三种是跨部门的内容汇稿。这种场景下，不同部门提交的文档格式差异最大，有的交PPT，有的交Word，有的直接丢个PDF，最后要合并成一份统一格式的交付物。遇到这种情况，系统层面能做到的有限，但对Word文档之间的合并，至少要保证内容能进来、大体格式不塌，不能要求用户一开始就把所有材料都做成标准格式，这不现实。
1.2 格式之外，最容易被忽视的三个隐性痛点
格式错乱是看得见的痛点，但真正让我决定做一个企业级系统的，是下面三个隐性痛点。
痛点一：版本管理混乱。 很多团队用文件名的“最终版”“最终版2”“最最终版”来管理版本，这种做法的后果是，合并时根本不知道哪一份才是真正的最新版本。如果系统不能提供一个明确的“基线版本”概念，并在合并前让用户确认各自操作基于哪一个版本，那么格式乱是小事，内容错乱才是大事。
痛点二：批注与修订的丢失。 企业文档在流转过程中，经常需要领导批注、同事修订。打开历史文档，满屏的红色修订标记看着烦，但真要合并的时候，这些批注和修订记录如果全部丢失，审阅过程就完全没有痕迹了。领导可能会问：我上次提的意见，你们改没改？——这时候如果文档里没有对应的批注记录和修订痕迹，你就是把嘴皮子说破了也没用。
痛点三：合并过程中的回溯与审计。 出了错总要有人负责吧？这不是追责的意思，而是说，当一个文档最终合并完成后，我们需要知道每个部分是谁写的、什么时候写的、最后一次修改的内容是什么。在没有系统支撑的情况下，这些信息分散在各人本地的文件里，根本无法追溯。企业文档往往是重要的项目资产，资产没有“来路记录”，将来出了问题就是一笔糊涂账。
这些问题合在一起，指向一个结论：企业级文档合并，本质上不是一个文件拼接问题，而是一个需要从格式、版本、流程、权限、审计等多个维度统一设计的系统工程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选对技术地基：OOXML格式拆解与合并可行性
要解决合并问题，就必须先搞清楚我们要处理的文件格式到底是什么。企业里用的Word文档，99%以上是docx格式。很少有人意识到，docx本质上是一个zip压缩包，里面是一堆xml文件的集合