如何合并和拆分 PDF，而且不上传文件
PDF 是人们用来存放真正在意的文档的格式：合同、发票、报税材料、病历、签过字的表格。这恰恰让它成为最不该随手交给某个网站的一类文件。
合并两个 PDF 不是什么困难的计算问题。它没有任何理由需要上传——而且在现代浏览器里，它确实不需要。
合并这件事到底在做什么
PDF 是个容器：一组页面对象、字体、内嵌图片，以及一张指向这些内容的交叉引用表。合并两个文件，就是构造一个新的容器，按你指定的顺序引用两个文件的页面，同时把它们各自依赖的资源一并带过去。
这正是浏览器库擅长的那类结构化文档操作。比如 pdf-lib 就在 JavaScript 里、在内存中构造和重写 PDF 结构，全程不涉及服务器。这个操作很快，因为根本没有东西需要传输——合并一个 50MB 的文件是按本地磁盘速度跑的，而不是按你的上传带宽。
合并步骤
- 打开 PDF 合并工具。
- 拖入两个或更多 PDF 文件。它们会直接从你的磁盘读进浏览器内存。
- 拖动缩略图，排成你想要的顺序。
- 点合并，下载结果。
没有任何上传。想确认的话，打开开发者工具、切到 Network 面板、跑一次合并——不会有任何请求携带你的文件。
没人提醒你的顺序问题
合并里最常见的错误是顺序搞错，这件事值得在动手之前想清楚，而不是事后补救。
页码会重新开始。 如果你合并的三份文档各自带页码，结果里就有三套页码，而且都不再有任何意义。如果合并后的文件会被打印或被引用，考虑加一个连续的页脚，或者调整合并顺序让它无所谓。
书签和目录通常保不住。 内部链接和导航面板是每份文档各自的结构，大多数合并工具会直接丢掉。如果读者需要靠它导航，就在文件名里说清楚，或者加一页封面。
表单字段会撞名。 两个 PDF 里都有叫 signature 的字段，合并时会冲突。要合并可填写的表单，先把它“扁平化”（flatten）。
体积是相加，不是平均。 一份 40MB 的扫描件加一张 2MB 的发票，得到 42MB。如果结果要发邮件，合并之后还得压缩。
合并之后
文件拼好之后，后续的常规操作都能在本地完成：
- 压缩 PDF —— 最大的收益来自对内嵌图片降采样，而扫描件的体积大头就在这里
- 重新拆开 —— 抽出一段页码范围，或者把大文件拆成单页
- 旋转页面 —— 专门对付总会混进来的那一页横向扫描
- 转成 Word —— 需要改内容而不只是拼文件时
- 把页面转成图片 —— 要把某一页放进幻灯片或网页时
这些全都基于同一个原理在浏览器里运行，没有一个会上传你的文档。
为什么“上传式方案”是个糟糕的默认值
大多数“合并 PDF”网站免费，是因为上传本身就是它的产品。一份合并后的文档常常就是签好的合同或财务记录——恰恰是对你以外的人有价值的那类材料。就算它写了删除政策，你也是在信任一个你无法核实、且针对一个你无法追踪的文件的说法。
如果 PDF 是公开的宣传册，上传无所谓。如果是合同、税务文件，或者任何上面有账号的东西，这点便利不值得你造出一个无法审计的副本。这笔账的推理过程写在在线文件转换工具安全吗里。
常见问题
能不能合并 PDF 而不上传？ 能。浏览器库可以完全在内存里读写 PDF 结构。本站的合并工具就是这么做的，你可以在浏览器的 Network 面板里验证。
合并的文件数量有上限吗？ 实际的限制是你设备的内存，而不是某个服务器配额。几十份常规文档合并起来毫无压力。特别大的扫描件则受可用内存限制。
合并会降低 PDF 的画质吗？ 不会。合并只是重组文档结构、原样搬运页面内容。和图片压缩不同，这里没有重新编码的步骤，所以什么都不会丢。
为什么合并后的文件变这么大？ 因为体积是相加的。扫描页通常以高分辨率图片存储，而这些图片就是文件的主体。压缩合并后的 PDF——也就是对这些图片降采样——通常就是解法。
手机上能合并 PDF 吗？ 能。浏览器端合并可以在手机浏览器里工作，因为计算发生在设备本地。小屏幕上界面紧凑一些，但结果完全一样。