合并 PDF

合并会把多个 PDF 的页面复制到一个新文档里，顺序由你决定。页面作为完整的成品对象被整体搬移——文字依然可以选中，页面上的链接照常可用，图片也保留原始数据。整个过程不做任何重新编码，所以合并后的文件在外观和行为上，都和把原文件并排摆在一起时完全一样。

整个操作都在你的浏览器里运行。这个页面没有任何上传接口——文件被读入内存，由在后台线程中运行的 PDF 引擎合并，再写回一个由浏览器下载的文件。正因如此，在你确认之前，顺序列表就能显示每个文件的页数：工具无需把文件发送到任何地方，就已经知道每个文件里有什么。

输出文件名为 merged.pdf，不带任何水印。如果某个源文档包含表单字段，结果卡片会提醒你：来自多个文件的字段可能发生冲突，因为 PDF 表单是按名称识别字段的，两份文档可能把同一个名称用在不同的字段上。加密 PDF 会在一开始就被拒绝，而不是被合并成一个损坏的结果。

从机制上说，没有任何东西离开这个标签页。页面把你的文件读入内存，PDF 引擎在后台线程里拼装出合并后的文档，结果直接写成下载文件——整个过程中没有任何请求把你的文档带往任何地方，页面也根本做不到：它的安全策略彻底阻止了对外连接。你可以在运行时盯着 Network 面板看；之所以这样构建，意义正在于此。无需账号、无需邮箱、没有水印、不存副本——服务器端根本不存在可以存下的副本。

合并是一个页面级工具：它合并的是整页，无法改动页面上的文字，无法压缩结果，也无法打开加密的输入文件。这些边界我们明确说明，而不是遮掩过去。要处理页面里的文字，Android 应用可以编辑原始文本对象；要处理加密文件，它可以在你的手机上用密码打开。如果你的合并主要是为了排顺序——哪一章接在哪一章后面——这个页面就能完成全部工作。

一次典型的操作是这样的：把 contract.pdf、scope.pdf 和 appendix.pdf 拖到页面上；在列表里看到它们分别是 4 页、2 页和 16 页；因为签署顺序变了，把 appendix 拖到 scope 上方；点击「合并 PDF」，二十秒后下载 merged.pdf。整个过程没有创建账号，没有留下邮箱，没有文件离开这台机器——涉及的四个文件只存在于你的磁盘上，其中三个仍原封不动地待在你拖出它们的地方。