PDF 合并这四个字，听起来是技术含量最低的一类需求，可只要真上手做过几次，就知道它跟“把几个 txt 拼在一起”完全不是一回事。文件少、只做一次、内容不敏感，随便找个在线站点点两下就完事；但只要你碰上“三百个扫描件要拼成一本”“合并完书签全没了”“合并后体积从 40M 涨到 400M”“表单填一个其它全跟着变”这类情况，就会发现不同方案之间的差距大到离谱。这篇就把我这些年处理 PDF 合并这件事的完整思路摊开讲：五种从小到大、从手动到自动的方法，各自的能力边界、操作细节、参数取舍，以及那些文档里不会写、只有踩过才知道的坑。

内容覆盖的读者范围我尽量放宽：偶尔要交作业、拼材料的人，看完前两部分就够用；每天要处理台账、汇总报表的办公岗，重点看方法二和方法三的校验清单；需要定期批处理几百上千个文件的人，直接跳到方法四和方法五。所有方法我都会说清楚“为什么选它”“什么时候别选它”，参数和命令都给到能直接复制运行的程度，中间夹着我自己的实操记录和排查经验。

1. 先看清楚：合并 PDF 到底在合什么

1.1 五种方法的能力地图：按文件数量、频率、隐私三个维度选型

很多人选工具是看“哪个名气大”，这个思路在 PDF 合并上特别容易翻车。真正决定你该用哪种方法的，是三个很朴素的变量：单次要合多少个文件、这件事你多久做一次、这些文件能不能离开你的电脑。把这三个变量想明白，方法基本就定了，剩下的只是操作细节。

从底层看，合并 PDF 的本质是把若干个独立文件的“页面树”重新挂到一棵新的页面树上。每个 PDF 内部都有一份对象编号表和一张记录对象位置的索引表，两个文件的对象编号几乎必然冲突，所以合并工具必须做重编号或者复制对象。这一步怎么实现，直接决定了输出的质量：做得好的工具只是搬页面、复用资源，体积接近原文件之和；做得糙的工具会把每页“重新渲染”成图片再打包，文字变图层、体积翻几倍、清晰度还下降。

这张表不是让你死记，而是给你一个判断顺序：先问文件能不能外传，不能就砍掉在线方案；再问数量，超过二三十个基本就别手动拖了；最后问要不要保留书签和表单，要的话在线站点多半满足不了。

1.2 合并之前的四道检查，能省掉后面九成的返工

我见过太多人拿到一堆 PDF 就直接开合，合完发现顺序乱了、页码重了、有几页是横的、还有两个文件打不开。这些问题的成因都藏在合并之前，花三分钟检查一遍，比事后返工半小时划算得多。

第一道是加密状态。有些文件打开不需要密码，但设置了“禁止复制、禁止修改”的权限位，这类文件在合并时经常被工具直接跳过或者报错，而且报错信息往往很含糊，你以为是文件损坏。判断方法很简单：单独打开它，看能不能选中文字、能不能另存为新文件，如果这些操作被拦，就需要先确认你是否有权处理，再决定怎么走。

第二道是页面尺寸和方向。A4、Letter、16 开混在一起是最常见的情况，合并工具默认不会自动缩放，输出文档里就会出现大小不一的页面。屏幕上翻着还行，一打印就露馅：同一份材料里有的页满版、有的页四周一大圈白边，装订起来参差不齐。扫描件更麻烦，因为扫描仪的分辨率设置不同，页面实际尺寸可能差出好几毫米。

第三道是你需要保留哪些“附属信息”。书签、目录、表单域、批注、图层、附件，这些东西统称为文档级结构，合并时是否保留完全取决于工具实现。特别提醒表单域：两个文件里都存在叫“姓名”“日期”的字段时，合并后它们有可能被绑成同一个字段，你填第一个，后面全跟着变，这种问题排查起来非常费劲。

第四道是体积和清晰度底线。这里有个认知误区要先纠正：合并不是压缩。合并解决的是“文件个数”，不解决“文件多大”。如果源文件是扫描件，每个都几十兆，合并完就是几十兆乘以个数，指望合并完变小是不现实的。

提示：合并完第一时间别急着发出去。先翻到每个源文件的交界处看页码衔接，再整体滚一遍看有没有空白页和方向错误的页，最后看文件属性里的页数是否等于各源文件页数之和。这三步一分钟能做完，能挡掉绝大多数低级事故。

2. 方法一：在线合并平台，零安装的应急方案

2.1 从上传到下载，六步走完一次合并

在线合并站点的价值就一个字：快。不用装东西，不用管系统版本，浏览器打开就能干。流程本身没什么技术含量，但每一步都有容易忽略的细节，我按实际操作顺序拆一遍。

第一步是选站点。判断标准不是界面好不好看，而是看它有没有明确写出“文件在多少小时后自动删除”，以及有没有说明文件是否会被用于其它用途。写得越具体越可信，含糊其辞的（比如只写一句“我们重视您的隐私”）就要留个心眼。

第二步是上传。多个文件可以一次性框选拖进去，注意上传顺序不一定等于你选择的顺序，有些站点是按文件大小或者按上传完成时间排的，所以别指望“我按顺序选的它就按顺序排”。

第三步是排序，这一步后面单独讲。第四步是选择合并模式，常见的选项有“全部合并成一个”“每若干页拆分后合并”“按书签层级合并”，大部分场景选第一个。第五步是点击处理并等待，文件大的时候会卡几十秒，别重复点。第六步是下载，下载下来的文件名通常是一串随机字符，先重命名再归档，否则过两天你根本认不出它是哪一份。

2.2 排序面板是被最多人忽略的一步

排序这件事看起来弱智，实际是出错率最高的环节。原因在于人的预期和界面的实际行为经常不一致。你在文件管理器里看到的顺序是按名称排的，上传到网站后它可能按修改时间排；你以为拖进去的第一个就是第一页，结果它排在末尾。

我的习惯是：上传前先在本地把文件名改成带序号的形式，比如“01-封面”“02-正文”“03-附件”，序号补零。补零这个动作很关键，因为不补零的话，按名称排序会变成 1、10、11、2、3，这是字符串排序的通病，后面讲命令行的时候还会再碰到一次。

上传之后，不管界面看起来多整齐，都要在排序面板里从头到尾扫一遍缩略图。缩略图能帮你确认两件事：顺序对不对，以及有没有混进不该有的文件（比如你框选时多选了一个“合并结果-副本”）。确实有站点提供“按文件名排序”的按钮，但它的排序规则未必和你本地一致，还是人工确认最稳。

2.3 三条不能越过的边界：隐私、体积、次数

在线方案有三条明确的红线，越过去就不是“不方便”的问题，而是“出事”的问题。

隐私这条线最硬。凡是涉及个人证件、体检报告、合同金额、内部台账、未公开的方案，一律不要上传。你可能觉得“我就传一次，谁会看”，但文件一旦离开你的设备，后续怎么存储、存多久、谁能访问，就完全不在你控制范围内了。这类文件要么走本地工具，要么在合并前把敏感页抽出来单独处理。

体积这条线经常被忽略。大部分免费站点对单文件有上限，常见是几十兆到一百兆，对总页数也常有限制。超了之后的报错往往很模糊，只说“处理失败”，你会以为是文件损坏，反复重试浪费半小时。上传前先看一眼文件大小，超了就直接换方案。

次数这条线是体验问题。免费站点普遍限制“每小时几次”“每天几次”，超了会排队或者要求等待。如果你正赶时间交材料，卡在这一步会非常被动。所以我的建议是：在线方案只作为“临时应急”，不要把它变成你处理这类任务的唯一手段。

3. 方法二：桌面端 PDF 编辑器的合并入口

3.1 完整操作流程与排序面板的实际用法

只要你每周都要处理几次 PDF，装一个桌面端的 PDF 编辑器就是最划算的投资。这类软件的合并入口通常藏在“组织页面”“页面管理”或者“工具”菜单下面，不同产品位置不一样，但逻辑相通：先导入文件列表，再调整顺序，再执行合并，最后另存。

导入环节有个实用技巧：直接把多个文件从文件管理器拖进软件的合并窗口，比一层层点“添加文件”快得多。拖进去之后，列表里每个文件左边会有一个小图标，点击可以展开看该文件的所有页面缩略图。展开这一步别省，因为有些文件里混着空白页、重复页、方向错误的页，在列表层面看不出来，展开才能发现。

排序环节支持两种粒度：文件级和页面级。文件级就是把整个文件当成一块整体上下移动，适合“这几份材料的先后顺序”这种需求；页面级可以把某个文件里的第 3 页单独拎出来插到别处，适合“把附件里的签字页提前”这类调整。页面级操作是桌面软件相对在线站点的最大优势，在线站点基本只能调文件顺序。

执行合并时，注意看有没有“优化文件大小”“保留书签”“保留图层”这类勾选项。默认值未必是你想要的：有些软件默认开启“优化”，实际做的是图像重压缩，输出体积小了但清晰度掉了；有些默认不勾“保留书签”，合并完目录就没了。第一次用某个软件，先拿两三个小文件做一次试验，把勾选项逐个开关对比输出结果，心里就有数了。

3.2 合并后必须做的四项校验

合并完直接另存、直接发出去，是新手最典型的操作。我用下面这张表做固定检查，四项走完不超过两分钟，但挡掉的事故数不清。

第三项和第四项是最容易被忽略的。页面尺寸问题在屏幕上看不明显，因为阅读器会自动适应窗口宽度，但打印时会原形毕露。文字可选中的问题更隐蔽：有些工具在“优化”时把整页转成了图片，你在屏幕上看着一模一样，等到要复制引用、要检索关键词的时候才发现全都选不中，那时候已经很难补救了。

3.3 高频场景下值得固化的两个习惯

第一个习惯是“先另存再合并”。原文件不要动，合并结果另存为新名字。听起来是废话，但我见过为了省事直接覆盖原文件的，合完发现顺序错了，原文件没了，只能重新找来源。

第二个习惯是给合并结果起一个能自解释的文件名，包含日期、内容和版本，比如“2024-05-项目材料汇总-v2”。这类文件往往要流转好几个人，文件名本身就是最便宜的版本管理。别用“合并.pdf”“新建 PDF 文档”这种名字，一周之后你自己都分不清哪个是最终版。

4. 方法三：办公套件里“先导出再合并”的回头路

4.1 什么情况下这条路反而更省事

这个方法听起来绕：先把各个源文档导出成 PDF，再合并。但如果你的原始材料本来就是可编辑的文档（文字处理文件、演示文稿、表格），这条路往往比“先各自导出再想办法合并”更顺，因为它能在导出环节就把页面尺寸、页眉页脚、页码这些东西一次性统一好。

判断要不要走这条路的信号很明确：如果各个 PDF 的页面尺寸不一致、页边距不一致、页码各自从 1 开始、字体大小不统一，那说明它们的“排版基因”不同，硬合在一起必然难看。这时候与其在合并后逐页修，不如回到源文档，把页面设置统一，把页码设成“续前节”，再一次性导出成一个文件。

具体做法是把所有源文档的内容按顺序放到同一个文档里，用分节符隔开，然后把页面尺寸统一设成同一规格，页码设置为“续前节”，最后整体导出为 PDF。这样出来的文件，页码是连续的、页边距是一致的、字体是统一的，很多原本要在合并后手工修的问题在源头就消失了。

4.2 让排版还原度接近原稿的三个操作

第一个操作是嵌入字体。导出时如果字体没有嵌入，换一台机器打开就可能变成替代字体，行距、字宽全变，原本排好的一页可能溢出到第二页。导出设置里找“字体嵌入”相关的选项，选“嵌入所有字符”最保险，代价是文件会大一些。

第二个操作是控制图片的压缩率。默认的导出设置通常会对图片做有损压缩，正文里的小图标看不出来，但整页插图或者带细线条的图表就会出现明显的色块和锯齿。如果材料里有图纸、表格截图、产品图，把图片压缩质量调高一档，或者选“不 downsample”。

第三个操作是留意分页位置。源文档在不同软件里打开，分页可能不一样，尤其是表格跨页和图片环绕的地方。导出前先在源文档里用打印预览过一遍，看看每一页的断点是否合理，该断的地方没断、不该断的断了，导出成 PDF 之后改起来更麻烦。

4.3 这条路的代价：体积与可编辑性

走这条路的代价有两个，得提前接受。一个是体积。从源文档导出的 PDF，字体全嵌入、图片不压缩，体积通常比“原样合并”大不少。如果只是内部传阅无所谓，要发邮件或者上传到有大小限制的系统，就得再做一次压缩。

另一个是可编辑性下降。合并后的文件里，每一页都是“排版结果”，不再是结构化内容。你想改一句话、调一个段间距，都得回到源文档改完重新导出。所以这条路的适用前提是：内容已经定稿，剩下的只是拼装。如果内容还会反复改，别急着合并，等定稿再合。

5. 方法四：命令行工具的批量合并

5.1 选工具的判断标准：看它是不是只重组页面树

命令行的 PDF 工具不止一款，选择时只看一个关键指标：它是“重组页面树”还是“重新渲染页面”。前者的输出里文字仍然可选、体积接近原文件之和、书签可以保留；后者会把每页画成图片，体积暴涨、文字消失。判断方法很简单，合并两个纯文字文件，看输出体积有没有翻好几倍，再看文字能不能选中。

我常用的组合是两个开源工具：一个专门做页面级的重组，命令形式是“从空文档开始，把若干文件的页面依次装进去”；另一个偏全能，除了合并还能做线性化、加密、拆分。两者都不需要图形界面，装完就能在终端里跑，适合写进定时任务。

安装上没什么坑，各平台的包管理器基本都有，装完用版本号命令确认一下就行。真正需要注意的是路径里有空格和中文的情况，命令里一定要给路径加引号，否则会被当成多个参数，报错信息还特别难懂。

5.2 十个文件的合并命令，以及通配符排序的陷阱

最直接的写法是用通配符把所有文件喂给工具：

# 最朴素的写法，按 shell 的通配符展开顺序 qpdf --empty --pages ./input/*.pdf -- ./merged.pdf

这行命令能跑通，但有个隐蔽的坑：shell 展开通配符用的是字典序，1.pdf、10.pdf、2.pdf会排成 1、10、2 的顺序。十个以内的文件你可能一眼看出来，几十个文件的时候，顺序错了很难发现，等到打印装订才暴露。

修正办法是用按自然数排序的方式生成文件列表：

# 按版本号自然排序，1、2、10 的顺序才对 qpdf --empty --pages $(ls -v ./input/*.pdf) -- ./merged.pdf

如果文件名本身没有规律，最稳的做法是老老实实写一个列表文件，一行一个路径，然后按行读取。写列表虽然笨，但顺序完全可控，而且这份列表本身就是处理记录，出了问题能回溯。

还有一个经常被忽略的点：--pages后面可以用“文件名 页码区间”的形式只取某个文件的某几页，比如只取第二个文件的第 3 到第 5 页。这个能力在“从一堆材料里抽取特定页拼成一份”的场景下非常好用，比先拆再合省事得多。

5.3 几百个文件怎么分批，避免一次吃满内存

文件数量上到几百个，一次性合并会有两个风险：内存占用飙高导致中途被杀，以及中途失败后要从头再来。我一般按 50 到 100 个一批，先合成分批文件，再把分批文件合成总文件。这个做法看起来多了一步，但有两个好处：单批失败只损失一批，不用全量重跑；分批文件本身也能作为中间产物留档。

# 第一批 qpdf --empty --pages $(ls -v ./batch1/*.pdf) -- ./part1.pdf # 第二批 qpdf --empty --pages $(ls -v ./batch2/*.pdf) -- ./part2.pdf # 合并分批结果 qpdf --empty --pages ./part1.pdf ./part2.pdf -- ./merged.pdf

分批的边界最好按业务逻辑切，比如按月份、按章节，而不是纯粹按数量切。这样中间产物是有意义的，万一最终合并出问题，你还能拿分批文件顶上。纯粹按数量切的话，中间产物基本没法单独使用。

注意：命令行工具处理加密文件时行为不一致，有的直接报错，有的静默跳过该文件，输出里就少了几页而你毫无察觉。批处理前先跑一遍检查，把打不开的文件挑出来单独处理，别让它们混在批里。

6. 方法五：脚本自动化合并

6.1 最小可用脚本：合并加自动加书签

当这件事变成周期性任务，比如每周要把几十个部门交上来的文件汇总成一份，手点和敲命令都不划算，写脚本才是终局。脚本相对命令行的最大优势是：可以在合并的同时做结构化处理，比如按文件名自动生成书签、按规则重新编页码、合并完自动校验页数。

下面这段是能直接跑的最小版本，逻辑是遍历目录、按自然序排、逐页追加、每加一个文件就挂一个一级书签：

import os, glob, re from pypdf import PdfWriter, PdfReader src_dir = "./input" out_path = "./merged.pdf" def natural_key(path): name = os.path.basename(path) return [int(t) if t.isdigit() else t for t in re.split(r"(\d+)", name)] files = sorted(glob.glob(os.path.join(src_dir, "*.pdf")), key=natural_key) writer = PdfWriter() cursor = 0 # 当前已写入的页数，也就是下一个文件起始页的索引 report = [] for path in files: reader = PdfReader(path) if reader.is_encrypted: try: reader.decrypt("") # 空密码尝试，仅适用于无打开密码的情况 except Exception: report.append((path, "跳过：无法解密")) continue n = len(reader.pages) for page in reader.pages: writer.add_page(page) title = os.path.splitext(os.path.basename(path))[0] writer.add_outline_item(title, cursor) # 书签指向该文件的首页 cursor += n report.append((path, f"已合并 {n} 页")) with open(out_path, "wb") as f: writer.write(f) for path, msg in report: print(f"{os.path.basename(path):40s} {msg}") print(f"总页数: {cursor}")

这段代码里有几个地方值得说清楚。natural_key是为了解决前面提到的字符串排序问题，不写这个函数，10.pdf就会排到2.pdf前面。cursor记录的是“下一个文件的第一页在整个输出里是第几页”，书签就是靠它定位的，这个偏移量算错，书签就会全部指向错误的位置。decrypt("")只对“没有打开密码”的文件有效，真有密码的会抛异常，所以我把它放在 try 里并把失败原因记进报告，而不是让整个脚本崩掉。

6.2 进阶处理：页码、加密、压缩

书签有了，下一步通常是页码。合并后的文件里，每个源文件自带的页码都从 1 开始，一份二十个文件的汇总材料里会出现二十个“第 1 页”。解决办法是在每页上叠加一层页码文字，这一层可以是独立的覆盖层，不影响原有内容。

思路是在内存里生成一个只有页码文字的空白页，尺寸和该页一致，然后把它叠加到原页面上。具体实现依赖你用的库，核心是把“页码文字”和“原页面”两个内容流合并，而不是把页面转成图片。这里要提醒一句：如果你用的库版本不支持内容流合并，退而求其次的做法是生成页码层再用别的工具叠加，千万不要用“打印到 PDF”的方式，那是重渲染，会把所有文字变成图片。

加密和压缩是两个独立动作，别混在一起做。加密用算法强度和两个密码（打开密码、权限密码）来控制，注意用了强加密之后，有些老版本阅读器可能打不开，交付前要确认接收方的环境。压缩则是另一回事，真正的压缩要针对图像对象做，把大图重采样、降低冗余，而不是把整页重编码。如果你的源文件主要是文字，合并后体积本来就不大，没必要压；如果主要是扫描图，压缩能省很多，但要盯着清晰度，别把可读的文字压糊了。

6.3 跑批之前的自检清单

脚本写好之后，第一次跑不要直接上全量。我的固定做法是先拿五个文件跑一遍，检查四件事，都过了再放全量。

第三项特别重要。脚本处理批量任务时最危险的不是报错，而是“安静地少干活”——某个文件因为权限或者格式问题被跳过了，但脚本照常往下跑，输出看起来完好无损，你也就这么交付了。所以一定要有一个显式的处理报告，把每个文件的处理结果打出来，让人能一眼扫到异常。

7. 常见问题与排查技巧实录

7.1 问题速查表

7.2 我在实际处理中总结的几条避坑经验

第一条是关于“优化”选项的。几乎所有带图形界面的工具都有一个默认勾选的“优化文件大小”，名字听起来无害，实际做的事可能是把图像重采样、把字体子集化、甚至把复杂页面栅格化。它带来的收益往往只有百分之十几的体积下降，代价却是不可逆的清晰度损失和文字不可选。我的做法是：第一次用某个工具，先关掉所有“优化”类选项合一次，再打开合一次，把两个输出放在一起对比体积和文字可选性，确认它到底做了什么再决定。

第二条是关于命名的。批量处理的场景里，文件名就是排序依据，也是书签来源，还是事后追溯的线索。我的命名规范是三段式：序号（补零）+ 内容描述 + 版本或日期。补零这件事我在命令行那一节提过一次，这里再说一遍是因为它真的太重要了——不补零的序号排序，在文件数超过九个之后必然出错，而这个错误在缩略图里几乎看不出来。

第三条是关于“先验证再全量”。批处理最怕的不是失败，是部分成功。一个两百个文件的任务，中间有一个文件因为权限问题被跳过，脚本正常退出，你拿到一份看起来完整的输出，页码连续、书签齐全，唯独少了某个部门的一整份材料。这种错误如果没被发现，后果比直接报错严重得多。所以我现在所有批处理脚本都会输出一份处理清单，逐条写明“已处理”或“已跳过及原因”，跑完先看清单，再看文件。

第四条是关于备份的。合并操作本质上是“读源文件、写新文件”，理论上不会破坏源文件，但总有工具在异常退出时留下不完整的结果，甚至个别工具会尝试“就地修改”。所以我在任何批量操作之前都会把源目录整体复制一份，尤其是在源文件来之不易（比如扫描了一下午）的情况下。这个习惯成本很低，救过一次就值回票价。

最后分享一个我觉得挺实用的小技巧：如果你的合并需求里，书签层级要求比较复杂（比如每个文件一个一级书签，文件内部的各章节作为二级书签），不要指望工具自动完成，直接从源文件的标题结构生成一份书签清单，然后用脚本按“标题 + 页码”批量注入。这样生成的书签结构是可复现的，源文件更新了重跑一次就行，比手工在界面里一条条加要可靠得多。