先说结论

合并是 PDF 里少数真正便宜的操作。PDF 是一个装着编号对象的容器：把两个文件合起来，就是把后一个文件的页面对象复制进前一个、重排引用编号、在末尾写一张新的交叉引用表。没有页面被重新渲染，没有图片被重新编码，也没有文字被重新排版。几百 KB 的 JavaScript 就够浏览器完成这件事。

这就是为什么断网也能合并。如果一个网站让你等着它"处理"文件，它其实不是在合并，而是在上传、在它控制的机器上合并、再把结果下载给你。

「文件不离开你的设备」是一句声明，不是一个机制。开发者工具的网络面板一眼就能验证：选文件的时候没有任何请求，那就是没有上传。

为什么这么多工具仍然上传

服务端合并更容易一次写好、卖给所有人：库成熟，手机不需要为 200 MB 的文档准备内存，同一套代码还能处理五十个文件的批量任务。它还顺便造出一个可以存放结果的地方——免费服务通常就是这样养活自己的：保留一段时间、给一个会过期的下载链接，偶尔在下载按钮前面加一道订阅墙。

这未必是欺骗，但它改变了你要信任的对象。你不再是在评估一次转换，而是在评估一家公司、它的留存政策、它的司法辖区，以及那个「删除」按钮是不是真的会删。

放进文件之前先看四件事

下面四个检查大约十来秒，对任何合并工具都适用，包括这一个：

  • 断网还能用吗？打开页面、断开网络、再合并。在浏览器里完成的合并照样能跑完。
  • 大小上限像内存上限还是商业上限？标签页通常几百 MB 才会撑爆；商业上限一般是个整数，比如 10 MB。
  • 下载前要不要注册？如果结果已经生成，账号提示就是营销步骤，不是技术步骤。
  • 页面有没有说文件之后会怎样？「一小时后删除」是留存政策，「从不上传」是另一种架构。

什么时候不该用浏览器

本地合并有真实的限制，动手前值得知道。标签页的内存比桌面程序少，一堆超大文件可能在原生工具里没事、在这里失败。带密码的 PDF 必须先解锁，因为不解密就复制不了页面对象。手机也会比笔记本更早撞到内存上限。

对于普通文档——合同、扫描件、票据、按章节拆开的论文——这些都不重要。服务器那边还没传完，这边已经合并好了。