一次合并真正复制的东西

发布于 2026-11-02 · 最近复核 2026-11-06

合并看起来就是「复制」，而人们被这个词骗两次：一次是签过字的合同合完回来，签名那几页还在，可它不再是「一份签过字的文件」；另一次是三个文件合起来，得到的那一份比三份加起来还大。两件事都出自 PDF 格式的同一个事实——合并只搬页，别的一概不搬——把机制摊开讲，这两件事就都能提前安排。这一篇讲机制，也讲标签页为此付出的账单。

文件从来没有离开这个标签页

文件是通过浏览器自己的文件选择器读进来的，字节直接落进你本来就开着的那个标签页里。页面接着逐份打开文档，用 JavaScript 把页搬进一份新文档，最后把结果做成一个 Blob 交给你下载。这句话里没有「上传」这一步，而对工资单、护照扫描件、医院信件来说，重要的正是这一步：文件没有出门，就没有服务器上的那一份副本需要被删除、被遗忘或者被泄露。

这也意味着活是有限的活：几十页的合并通常不到一秒，慢的是从磁盘读文件，不是搬页。这一篇解释的是 合并 PDF，它在写任何东西之前就把每一份输入的页数与体积印出来。

页面带走内容，文档才带那些「附属结构」

一份 PDF 是编号对象的容器——页面、字体、图片、绘图指令的流——由一棵页面树和一张交叉引用表把它们串起来。合并读的是每份输入的页面树，把页对象以及它们指向的资源搬进一份新文档，再为结果写一张新表。整个过程不重新渲染，所以文字仍然是文字：合并后的文件照样能选中、能搜索，图片保持原来的分辨率，矢量图放到任何倍数都清楚，每一页的尺寸与方向也各自保留。

而那些「整份文档只有一份、不挂在某一页上」的东西，全都不会被带走，这也恰好是事后才发现的那张清单：书签与目录大纲、可填写表单里的字段、数字签名的签名域、图层可见性、读屏软件跟随的结构标记。所以合并出来的文件是「没有打标签」的；一份签过名的文件合并之后就不再是可验证的签名文件——看得见的那块签名作为页面内容留下来了，密码学上的那份证明不保留。加密文件会被直接拒绝，而不是合到一半：这一页没有输入密码的地方，猜着打开一份加密文档，得到的只会是一个坏文件而不是一句错误。

一次合并要标签页付出多少内存

真正的上限是内存，它的形状值得知道。合并期间，输入的字节和输出的字节是同时存在的——必须如此，因为新文档是在旧文档还在被读的时候写出来的——所以峰值大约是作业上限的两倍。这个工具的上限是每份 25 MB、单个作业 80 MB、一次最多 20 个文件，算下来峰值接近 160 MB，还不包括 PDF 处理引擎解析出来的对象图。

这些数字是预算，不是偏好。标签页内存不够的时候不会给出一句有用的错误，它会被直接杀掉，通常连做到一半的活一起消失，屏幕上什么解释都没有。分批合并能得到同样的结果，而且稳稳留在预算之内。这也解释了为什么输出可以比输入加起来更大：每份输入都把自己的字体与图片带了过来，文件之间没有任何去重——两份文件嵌了同一个字体，合并结果里就有两份。

这些数字从哪里来

• 合并这件事由本站自己完成。搬页、输出顺序、每份输入贡献了多少页，都遵循同一套合并步骤，而每次发布都会自动核对它们。工具页与这一篇用的是同一套步骤，所以它们不可能对同一组文件给出两个答案。
• 上限是一组公布出来的固定数字，在读第一个字节之前就会检查。拦住超大作业的那条线与上面几段引用的是同一组上限，而这里的 25 MB 与 80 MB 是由这组上限直接换算出来的，不是手写进正文的。
• PDF 那一半靠的是 PDF 处理引擎，不是猜测。它按 MIT 许可跑在你的浏览器里；保留什么、不保留什么，是 PDF 格式「页 / 文档目录」这个分工决定的，不是本站挑的一个开关。

这一篇没有说什么

它不教你怎么把书签加回合并后的文件：那得事后在 PDF 编辑器里补，因为目录大纲是文档级结构，而合并写出的是另一份文档。它也不做压缩——合并是无损的，刻意不重新编码图片，所以人们指望「PDF 压缩」带来的那点体积下降是另一件事，本站把它放在单独一页。它同样不建模 OCR：扫描页在合并之后仍然是文字的一张图，无论文件怎么排，而这一页讲的是排法，不是识别。

拿你自己的文件到合并 PDF工具里看上面说的页数与体积，用 拆分 PDF 把其中一部分拆出来，或者在顺序定下来之后用 压缩 PDF 把结果压小。

以上只是解释与估算——不构成关于签名文件的法律意见。 阅读完整免责声明。