5分钟搞定pdf文件怎么合并：图解原理与3种方案硬核对比

看了一堆教程还是不会写项目？别怪自己笨，是那些文章只教你“点哪里”，没给你讲透底层逻辑。

做开发或数据处理，遇到【pdf文件怎么合并】这种需求太常见了。但网上搜到的答案，要么全是截图让你鼠标点点点，要么直接甩个库名让你自己研究。结果呢？代码复制下来，跑不起来，或者合并完页面顺序乱了、字体丢了，还得重来。

今天咱们不整虚的，直接上【图解原理】。我会把 PDF 合并这事儿拆开揉碎，对比 Python 三大主流方案：PyPDF2、pypdf 和 pdfunite（命令行工具）。咱们不光看代码，更要看它们是怎么在内存里处理字节流的。只有懂了原理，下次遇到“合并后文件打不开”或者“加密 PDF 合并失败”这种坑，你才知道往哪儿查。

1. 三种方案的定位与核心差异

在动手写代码前，先搞清楚这三个家伙分别是什么来头。很多新手一上来就装 PyPDF2，用了两年发现它已经停止更新了，这才慌了神。

PyPDF2：老大哥。以前 Python 处理 PDF 的绝对主力。它的 API 设计比较老派，面向对象，功能全，但代码写得有点啰嗦。现在官方已经归档（Archived），不再推荐用于新项目。

pypdf：新生代。它是 PyPDF2 的重写版，由原作者主导。性能提升了约 30%，API 更现代，支持更好的 Python 3 特性。目前社区最推荐的新项目选型。

pdfunite：轻量级命令行工具。来自 poppler 库，Linux 下几乎预装。它不依赖 Python 环境，速度极快，适合在 CI/CD 流水线或服务器端做批量处理，不适合复杂逻辑控制。

为了让你一眼看清区别，我整理了下面这张表。建议收藏，选型时直接对照。

特性维度	PyPDF2 (旧版)	pypdf (新版)	pdfunite (命令行)
维护状态	已归档，仅修复严重 Bug	活跃开发，持续更新	活跃，跟随 poppler 版本
安装依赖	`pip install PyPDF2`	`pip install pypdf`	`apt-get install poppler-utils`
语言绑定	Python	Python	C++ (通过 shell 调用)
加密支持	较弱，部分场景报错	增强，支持密码解密合并	极强，底层 C 实现
性能表现	中等	较快 (优化了对象查找)	最快 (无 Python 解释器开销)
跨平台	全平台	全平台	主要 Linux/Mac，Win 需额外配置
适用场景	维护旧代码	新项目首选	服务器批量、脚本化任务

划重点：如果你是写新项目，直接选 pypdf。别问为什么，问就是官方建议。PyPDF2 只在维护老代码时出现。pdfunite 则适合那些不想引入 Python 依赖，或者追求极致速度的场景。

2. 图解原理：PDF 合并到底在做什么？

很多人以为合并 PDF 就像合并两个 txt 文件，把内容接在后面就行。大错特错。

PDF 不是简单的文本流，它是一个树状结构。你打开一个 PDF，里面其实包含：

Pages 树：记录有哪些页，顺序如何。
Objects 对象池：存储具体的字体、图像、文字内容。
Catalog 目录：指向 Pages 树和元数据。

合并的本质，不是拼接字节，而是合并对象树。

想象一下，你手里有两个文件夹（两个 PDF）。

PDF A 里有 Page1, Page2，还有对应的字体 FontA。
PDF B 里有 Page3, Page4，还有字体 FontB。

如果你简单地把 B 的文件字节追加到 A 后面，计算机根本不知道 Page3 属于哪个目录，也不知道 FontB 在哪里。

所以，pypdf 或 PyPDF2 做的事情是：

解析 A 和 B 的对象树。
创建一个新的“主目录”。
把 A 的页面节点和 B 的页面节点，按顺序链接到新的 Pages 树中。
把 A 和 B 的所有字体、图片等对象，去重后塞进新的对象池。
生成新的交叉引用表（xref table），告诉计算机每个对象在文件里的偏移量。

这就是为什么有时候合并两个很大的 PDF，内存占用会飙升——因为它要把所有对象加载到内存里重新索引。

3. 代码写法对比：从入门到避坑

光说不练假把式。下面我们用同一个需求：将 doc1.pdf 和 doc2.pdf 合并为 merged.pdf，分别用三种方式实现。

方案一：使用 pypdf (推荐)

这是目前最标准、最安全的写法。

from pypdf import PdfWriter, PdfReaderdef merge_pdfs(input_pdfs, output_pdf):"""合并多个 PDF 文件:param input_pdfs: 输入 PDF 文件路径列表，顺序即合并顺序:param output_pdf: 输出文件路径"""writer = PdfWriter()for pdf_path in input_pdfs:reader = PdfReader(pdf_path)# 逐页添加，这是关键for page in reader.pages:writer.add_page(page)# 写入文件with open(output_pdf, "wb") as f:writer.write(f)print(f"合并完成: {output_pdf}")# 使用示例
merge_pdfs(["doc1.pdf", "doc2.pdf"], "merged.pdf")

代码解析：

PdfWriter 是构建新 PDF 的容器。
PdfReader 负责解析源文件。
writer.add_page(page) 是核心操作，它会把页面的引用加入新树，而不是复制整个页面数据（如果对象已存在）。
注意：pypdf 对加密 PDF 支持更好，如果源文件有密码，需要先在 PdfReader 初始化时传入 password 参数。

方案二：使用 PyPDF2 (兼容旧代码)

如果你还在维护老项目，或者环境里只有 PyPDF2，写法类似，但类名不同。

from PyPDF2 import PdfFileWriter, PdfFileReaderdef merge_pdfs_legacy(input_pdfs, output_pdf):writer = PdfFileWriter()for pdf_path in input_pdfs:reader = PdfFileReader(pdf_path)for page_num in range(reader.getNumPages()):page = reader.getPage(page_num)writer.addPage(page)with open(output_pdf, "wb") as f:writer.write(f)# 注意：PyPDF2 的 API 是小驼峰命名，如 getNumPages, addPage
merge_pdfs_legacy(["doc1.pdf", "doc2.pdf"], "merged_legacy.pdf")

坑点提示： PyPDF2 在处理某些非标准 PDF 时，容易抛出 PdfReadError。Stack Overflow 上有大量关于 PyPDF2 解析失败的帖子，很多是因为 PDF 结构损坏或缺少 xref 表。如果报错，尝试用 Adobe Acrobat 重新保存一下源文件，或者换用 pypdf。

方案三：使用 pdfunite (命令行/Shell)

如果你是在 Linux 服务器上写脚本，或者不想依赖 Python，这是最快的选择。

#!/bin/bash# 定义输入文件和输出文件
INPUT_FILES=("doc1.pdf" "doc2.pdf" "doc3.pdf")
OUTPUT_FILE="merged_shell.pdf"# 使用 xargs 传递多个文件给 pdfunite
pdfunite "${INPUT_FILES[@]}" "$OUTPUT_FILE"if [ $? -eq 0 ]; thenecho "合并成功: $OUTPUT_FILE"
elseecho "合并失败，请检查文件是否损坏或加密"
fi

优势：

没有 Python 解释器的启动开销，处理几百个文件时，速度比 Python 快得多。
内存占用极低，因为它流式处理，不会把所有页加载进内存。
劣势：无法在代码中灵活控制逻辑，比如“只合并第 1-3 页”或“跳过加密页”，这些需求它做不到，必须预处理。

4. 进阶技巧与避坑指南

实战中，你遇到的绝不仅仅是“把 A 和 B 合起来”。这里分享几个高频踩坑点和解决方案。

坑点 1：合并后页面顺序错乱

现象：你明明按 ["a.pdf", "b.pdf"] 的顺序传参，结果 b 的页面跑到 a 前面了。原因：某些 PDF 的 Pages 树顺序与物理存储顺序不一致（例如通过某些工具编辑过的 PDF）。解决：不要依赖文件内部的页序，而是在代码中显式指定页码索引。

# 示例：只合并 a.pdf 的第 1 页和 b.pdf 的第 2 页
writer.add_page(reader_a.pages[0])
writer.add_page(reader_b.pages[1])

坑点 2：字体缺失或乱码

现象：合并后，某些中文字体变成方块，或者英文字体变得很粗。原因：两个 PDF 使用了不同的字体子集，且对象 ID 冲突。虽然 pypdf 会做对象重映射，但某些特殊的嵌入字体（尤其是 Type3 字体）可能在合并时丢失元数据。解决：

确保源 PDF 字体已嵌入（用 Adobe Acrobat 的“预检”功能检查）。
如果是简单文本，建议先转换为 PDF/A 格式再合并。
实在不行，用 pdfunite 试试，它对底层对象的保留更完整。

坑点 3：大文件合并内存溢出 (OOM)

现象：合并 500MB 的 PDF 时，Python 进程被 kill。原因：pypdf 默认会将所有页对象加载到内存以构建新树。解决：

分块合并：不要一次合并 100 个文件。先合并前 10 个为 temp1.pdf，再合并后 10 个为 temp2.pdf，最后合并 temp1 和 temp2。
切换工具：改用 pdfunite。它在 C 层处理，内存效率远高于 Python。
清理内存：在循环中，及时 del reader 并调用 gc.collect()（效果有限，但聊胜于无）。

坑点 4：加密 PDF 无法合并

现象：PdfReadError: PDF file is encrypted。解决：

reader = PdfReader("encrypted.pdf", password="123456")

注意：密码必须正确。如果 PDF 是“只允许打印，禁止编辑”的权限加密，通常可以正常读取和合并，但输出文件会保留权限限制。如果需要去除权限，需要专门的解密库，且涉及法律风险，慎用。

5. 选型建议与总结

回到最初的问题：pdf文件怎么合并，我该选哪个？

我的建议非常明确：

新项目、Python 后端、需要灵活逻辑：
- 选 pypdf。
- 理由：活跃维护，API 清晰，社区支持好。Stack Overflow 上搜 pypdf merge 能拿到最新且准确的解决方案。
- 代码量：约 10 行。
维护旧项目，不想改动代码结构：
- 选 PyPDF2。
- 理由：兼容性最好，老代码直接跑。但记得锁定版本，别升级。
- 代码量：约 10 行。
Linux 服务器、批量处理、追求速度、无 Python 环境：
- 选 pdfunite。
- 理由：快、稳、省资源。
- 代码量：Shell 脚本 3 行。
前端用户、非技术人员：
- 别用代码，直接推荐在线工具或 Adobe Acrobat。写代码是为了解决批量和自动化问题，如果用户只有 2 个文件，让他点鼠标比让他装 Python 环境友好得多。