浏览器 PDF 合并/拆分：为什么更私密

2026-04-13发布 8分钟阅读

摘要 (TL;DR)

上个月我要把 47 张扫描的合同（共 230MB）合并成一个文件交给对方。我差点又顺手打开常用的在线 PDF 工具，但发现文件名里直接写着对方的真实姓名，于是停了下来。最终用 pdf-lib（v1.17.1）在一个普通浏览器标签里搞定，M2 MacBook Air 上大概 18 秒，风扇都没转。从那以后，敏感 PDF 我都先在浏览器里试。

PDF 合并和拆分不再是非要交给别人服务器才能做的事。最近的 Web 标准和基于 WebAssembly 的 PDF 库（pdf-lib、PDFium 移植、MuPDF.js 等）让中小体积文档完全可以在浏览器内快速处理。这种方式最大的优点是文件不离开网络边界——没有上传，就不会有服务器日志、临时存储、备份和泄露路径。代价是几百 MB 以上的大文件、OCR 和图像扫描重压这类 CPU 密集任务，以及一些加密文档的复杂签名处理上，服务器端工具仍可能更合适。简单说，敏感度高且体积合理时，优先在浏览器处理；大体积、复合 OCR、复杂电子签名保留时，选择经过验证的服务器工具或本地桌面应用更稳妥。

背景与概念

PDF 不是简单的图像，而是基于对象的文档格式。文件由很多间接对象（indirect object）组成，每个对象通过文件末尾的交叉引用表（XRef table）按字节偏移寻址。现代 PDF 还会用 ObjStm 这类对象流把多个对象一起压缩存储，发布时也常常带着增量更新区段。所以合并不是”把两个文件接在一起”，而更像是把一个 PDF 的对象图复制进另一个 PDF 的命名空间，然后重写新的 XRef 表。

拆分其实是反过来的同一件事。只保留一部分页面时，必须遍历这些页面引用的字体和图像资源，只把实际用到的带过来，把断掉的引用重新接好，结果才是一个有效的 PDF。pdf-lib 这类浏览器端库完全用 JavaScript + WebAssembly 实现这套流程，意味着字节不出设备就能产出符合规范的输出。

性能方面，今天的浏览器标签可以用 SharedArrayBuffer、WebAssembly SIMD，部分构建甚至能通过 web worker 多线程跑。成熟的库借助这些来加速图像解码、deflate、加密运算。你最先撞上的天花板通常是内存而非 CPU——浏览器标签对可寻址内存通常有几 GB 的软上限，加载 500MB 的 PDF 加上解压后的内容流可能逼近这个边界。但对绝大多数业务文档（个位数 MB 范围），这条天花板根本看不到。

对比与数据

维度服务器端浏览器端
隐私文件上传，可能被临时存储文件只在设备内处理
小文件（几 MB）速度往返延迟主导通常更快感受
大文件（100MB+）处理专用 CPU、内存有优势可能撞上浏览器内存上限
离线使用不可能可以
数据残留风险依赖服务方策略与日志结构上很低
高级功能（OCR、复杂签名）成熟工具多取决于具体库实现

把这张表当作形状而不是分数。实际感受速度由”文件大小 × 网速 × 服务端处理时间”组合决定。在合并 20–30 个几 MB 文档的办公场景，浏览器因为省掉上传往返，常常更快。

值得区分的是**“在服务器上处理”和”发送到服务器”是两件事**。一些混合服务在浏览器里加密后再上传，只处理密文。这比明文上传好，但仍需信任服务方的实现和密钥处理。纯浏览器工具的威胁模型更简单：因为没有发送，所以没有可验证的对象。

实战场景

场景 1 — 合同包打包。把合同、附件、附录合成一个文件交给对方时，浏览器端合并最大的优势是文件根本不离开本地。我见过两家公司的法务团队都明令禁止使用第三方在线 PDF 合并器——一家是因为草拟的 NDA 出现在了搜索引擎索引里，另一家是终于有人读完了某免费工具 30 天保留条款。法务、HR、财务文档很多在内部都被分类为”禁止外部上传”，浏览器流程从结构上就在这条边界内。

**场景 2 — 小册子拆分。**把 100 页的培训资料拆成 14 章发布是浏览器的理想用例。我上个季度就这么做的，错指了一次页面范围只要按一下 Cmd-R 重启大约 4 秒，而不是再走一次重新上传周期。往返被消除，迭代很快，万一出错原文件也只在本地，不会散布到外部服务上。

**场景 3 — 给扫描文档减肥。**扫描版 PDF 是图像驱动的，往往很大。我曾收到一份 48MB 的合同扫描件，分辨率 650dpi，但其实 200dpi 就够清楚——只是在合并之前重采样嵌入图像，整个包就降到了 11MB。合并前先把图像转成合适的格式和分辨率，比合并后再压缩有效得多。

**场景 4 — 分享前的脱敏。**常见错误是用一个黑色矩形”盖住”敏感文字，但底层文字仍可被搜索和复制。正确的脱敏需要删除文字对象本身，再重新展平页面。在你能控制的设备上做（本地桌面应用或不上传的浏览器工具）能在你弄错流程时缩小爆炸半径。

常见误解

**“浏览器工具慢。“**这在 2015 年是对的，但自 Chrome 91 和 Safari 16.4 支持 WebAssembly SIMD 与 worker 线程后情况变了。在我的设备上，pdf-lib 合并 5 个 10MB 的 PDF 大约 1.3 秒；同样的任务过一个快服务器服务，加上上传-排队-下载往返要 10 秒以上。日常办公任务你很少能感觉到差别——能感觉到的时候，通常浏览器更快。

**“服务器永远更快。“**上传、排队、处理、下载是串起来的链条。网速慢或服务繁忙时，本地浏览器工具可能在上传完成前就结束工作了。

**“浏览器处理无法支持审计追踪。“**如果是受监管的审计场景，请用专门的企业系统。但日常的合并/拆分/页面重排很少需要这套合规机制，把它们当作审计对象来对待是过度工程。

**“加密 PDF 必须服务器处理。“**AES-128/256 解密这种标准功能浏览器库支持得很好。但特定机构使用的非标准签名或策略文件可能需要专门工具，承诺工作流前先核对库的兼容性。

“免费工具一定在卖我数据。“这种怀疑是合理的，但不是必然。免费的服务器端 PDF 工具确实有时会变现上传内容；免费的浏览器端工具结构上做不到，因为文件根本没离开设备。区分最快的方式是在工具处理时盯一下网络面板，如果没有携带 PDF 字节的请求，那它就是纯本地的。

**“我可以直接邮件发给自己。“**邮件作为文档传输通道没问题，但不是处理管线。邮件服务器可能保留副本，附件可能被第三方扫描，转发的邮件可能流到你不希望的地方。敏感的合并/拆分工作，先在本地做完，再只把成品发出去。

决策清单

  1. 文档包含个人或机密信息吗？
    • 是 → 优先浏览器处理。
  2. 文件总体积多大？
    • 50–100MB 以下：浏览器可以从容处理。
    • 几百 MB 以上：考虑本地桌面应用或可信赖的服务器工具。
  3. 需要 OCR、高级签名或合规审计追踪吗？
    • 需要 → 考虑专用工具（本地或企业服务器）。
  4. 是高频重复任务吗？
    • 是 → 浏览器配合书签和快捷键的工作流通常更顺手。
  5. 需要离线作业吗？
    • 是 → 用带 service worker 缓存的 Web App 或桌面应用。
  6. 结果通过什么方式分享？如果会生成可分享链接，确认分享服务不会注入额外追踪。
  7. 文档是否带了你不想发出去的元数据？作者名、编辑软件、修订历史经常会在导出 PDF 里泄漏，发布前考虑剥离元数据。

如果你在主要数据保护法规下作业，记住把数据传给处理方会触发义务。欧盟 GDPR、加州 CPRA、韩国 PIPA 都把”将个人数据上传到第三方服务”视为需要记录、对跨境传输还需正当性证明的处理活动。浏览器端工具通常根本不构成传输，因为数据没离开数据主体的设备。这不是法律意见而是工作流观察，但这正是很多隐私团队倾向于本地工具处理日常文档的原因。

相关工具

本文描述的浏览器端流程可以直接在 Patrache Studio PDF 合并工具 里试。如果合并前要给扫描密集的文档减肥，先看 图像压缩完全指南 选好嵌入页面的格式。如果合并后的 PDF 要带可扫描的二维码做发布，二维码安全 讲了静态码与动态码在隐私和长期可用性上的取舍。

参考资料

相关工具

tools.patrache.studio/pdf/merge/