浏览器里已经加上高亮和备注，刷新后却全没了。可能是应用只修改了当前阅读器中的文档，没有把修改后的PDF保存到服务器；也可能保存成功，重新打开的仍是旧地址。
可下载教学输入、实际产物与示例代码对照检查。包内不含API密钥、SDK许可或SDK安装包。
下面按“打开、批注、导出、上传、重开”检查一遍，适用于业务系统中的单人审阅流程。
先把批注加到当前文档
按React接入步骤准备Web SDK、运行资源和许可，先打开一份教学PDF。给首页写一条“核对交付日期 DEMO-042”的备注。保留源文件，避免测试时覆盖原件。
本篇使用ComPDF的文档导出方式。批注的显示与编辑由SDK处理，业务系统仍需决定文档权限、保存位置和版本。
导出修改后的PDF，再上传
在当前文档加载完成、用户点击保存时执行下面的代码。docViewer来自已初始化的ComPDF实例；saveUrl是应用自己的保存接口，不是ComPDF接口。
async function saveReview(docViewer, saveUrl) {
const bytes = await docViewer.exportPDF();
const form = new FormData();
form.append('file', new Blob([bytes], {
type: 'application/pdf'
}), 'reviewed.pdf');
const response = await fetch(saveUrl, {
method: 'POST',
body: form,
credentials: 'same-origin'
});
if (!response.ok) {
throw new Error(`保存失败：HTTP ${response.status}`);
}
return response;
}
导出API可对照保存PDF文档。保存接口必须校验权限、文件与原版本，并在写入成功后返回确认；若接口返回202，只表示已受理，还要等后台完成。不能只凭HTTP状态就假定文件已持久化。
保存期间禁用重复提交，并处理异常提示。采用Cookie认证时，沿用应用已有的CSRF防护；不要把这段上传代码当作完整后端。
实际保存与重开结果
本次使用React 19.2.0、ComPDF Web SDK 2.9.4和两页教学PDF。备注导出后上传到本地教学服务，服务器确认写入47,615字节；刷新整个页面后，再从保存地址加载，备注内容仍是“核对交付日期 DEMO-042”。
另外重新读取落盘PDF，首页存在/Text批注对象，其内容与备注一致，页数仍为2。浏览器内存、服务端文件和重新打开后的内容分别核对，避免只验证了其中一环。
这份教学服务只演示保存，不包含生产环境的身份认证、权限或版本冲突处理。完整工程只提供自编代码与依赖声明，SDK和许可从官方渠道取得。
真正的检查在重新打开之后
关闭当前阅读器，使用服务器返回的新版本地址重新加载。检查高亮位置、备注内容、文档页数，并下载副本用另一款阅读器打开。
如果浏览器里有批注，而下载文件没有，应检查导出的是否为当前实例。下载文件正确、重开却丢失，则查上传结果、读取地址和缓存版本。这样能把问题定位到具体步骤。
图：本轮教学输入的实际检查结果；适用范围与未通过项见正文。
再处理文档切换和冲突
保存时绑定文档ID与原版本。切到B文件后，A的保存回调不能把B界面标成“已保存”。两人同时修改时，服务端也要检测版本冲突，避免后一次上传静默覆盖前一次。
需要给业务产品加入持续审阅能力时，可先用Web SDK试用跑通这条流程。批注保存通过后，再验证权限和多人协作要求；本篇的文件保存方案不等于实时协同编辑。
