踩坑实录：ONLYOFFICE forcesave 的同步化处理
背景 最近在做一个在线文档协作系统，用户可以在平台上编辑文档，编辑完成后触发一系列业务流程——生成版本、数字签名、归档等。文档编辑器选用了 ONLYOFFICE，功能强大，协作体验也好。 看起来是个挺常规的需求，对吧？ 我当初也是这么想的。直到系统上线后，用户反馈"数字签名偶尔会失效"，我才意识到自己踩进了一个不大不小的坑里。 问题出在哪？ ONLYOFFICE 的架构中，文档编辑和文件存储是分离的。用户在编辑器里修改文档，改动先停留在 ONLYOFFICE Document Server 的内存中，并不会立即写入你的存储后端。 ONLYOFFICE 提供了 forcesave 接口，可以强制保存文档。我最初的实现是这样的： // 用户点击"提交"按钮时触发 public void submitDocument(String documentId) { // 1. 调用 forcesave onlyofficeService.forceSave(documentId); // 2. 获取文件内容 byte[] fileContent = storageService.getFile(documentId); // 3. 生成数字签名 String signature = signService.sign(fileContent); // 4. 保存签名记录 recordService.saveSignature(documentId, signature); } 看起来逻辑清晰，没什么问题。但上线后，用户反馈：某些文档的数字签名校验失败。 排查后发现：当用户打开文档验证时，文件内容和签名时不一致——明明签名后没人再编辑过，怎么文件变了？ 根本原因：forcesave 是异步的 翻了 ONLYOFFICE 的文档，才发现 forcesave 的调用流程是这样的： 后端调用 forcesave API ↓ ONLYOFFICE Document Server 接收请求 ↓ Document Server 在内部调度保存任务（异步） ↓ 保存完成后，Document Server 回调后端的 Callback Handler ↓ 后端在回调中收到最新的文件 URL 也就是说，forcesave() 返回时，文件还没保存完成。真正的文件更新是在回调里发生的。 ...