前言
做 PDF 翻译预处理时，第一步永远是"把文本从 PDF 里干净地拿出来"。这一步的选型直接决定后面整条流水线的质量：提取出来的文本顺序乱了，翻译对齐就废；坐标信息丢了，版面重建就没戏。网上三库对比的文章不少，但大多停留在"都能提取文本"的层面。本文以翻译预处理为视角，在真实的 30 页报告 PDF 上跑了一轮量化实测，把文本速度、表格提取、坐标信息三个硬指标摆出来，结论直接可用。
测试环境：Windows 11，Python 3.13，pymupdf 1.28.2 / pdfplumber 0.11.10 / pypdf 6.18.0。
评测对象
- PyMuPDF（import pymupdf） ：基于 MuPDF C 库，主打速度和渲染能力，1.28 起官方推荐
import pymupdf。 - pdfplumber：基于 pdfminer.six 的封装，API 友好，表格提取是招牌功能。
- pypdf：纯 Python 实现，零编译依赖，pypdfium/pikepdf 生态之外的轻量选择。
测试文档构造
用 fpdf2 生成一份 30 页的英文报告 PDF（36 KB），每页含 6 个小节标题+段落，页尾一张 4 行 3 列的表格。全文 41090+ 字符，纯文本型 PDF（非扫描件）。生成脚本：
python
from fpdf import FPDF
pdf = FPDF()
pdf.add_page()
pdf.set_font("helvetica", "B", 16)
pdf.cell(0, 10, "Quarterly Report - Section 1")
# ... 正文段落 + 页尾表格（Region/Revenue/Growth）
pdf.output("test_report_30p.pdf")评测代码
python
import time, pymupdf, pdfplumber
from pypdf import PdfReader
PDF = "test_report_30p.pdf"
# --- PyMuPDF ---
t0 = time.perf_counter()
doc = pymupdf.open(PDF)
mu_text = "\n".join(p.get_text() for p in doc)
mu_time = time.perf_counter() - t0
t0 = time.perf_counter()
mu_tables = [t for p in doc for t in (p.find_tables().tables)]
mu_table_time = time.perf_counter() - t0
# --- pdfplumber ---
t0 = time.perf_counter()
with pdfplumber.open(PDF) as pdf:
pl_text = "\n".join(p.extract_text() or "" for p in pdf.pages)
pl_time = time.perf_counter() - t0
t0 = time.perf_counter()
with pdfplumber.open(PDF) as pdf:
pl_tables = [t for p in pdf.pages for t in (p.extract_tables() or [])]
pl_table_time = time.perf_counter() - t0
# --- pypdf ---
t0 = time.perf_counter()
pp_text = "\n".join((pg.extract_text() or "") for pg in PdfReader(PDF).pages)
pp_time = time.perf_counter() - t0
print(len(mu_text), mu_time, len(pl_text), pl_time, len(pp_text), pp_time)评测结果
文本提取速度与完整性
| 库 | 提取字符数 | 耗时（30页） | 相对速度 |
|---|---|---|---|
| PyMuPDF | 41120 | 0.042 s | 1x |
| pypdf | 41090 | 0.075 s | 1.8x |
| pdfplumber | 41090 | 0.780 s | 18.6x |
三个库提取的文本内容抽样比对完全一致（段落顺序、换行位置都相同），字符数的 30 字差异来自 PyMuPDF 对空白字符的处理略有不同。翻译预处理场景下三库的文本质量都在及格线以上，差异主要在速度和附加能力上。
这个"三库结果一致"其实值得多说一句：文本型 PDF 的字符映射（ToUnicode CMap）是规范操作，谁来读都是同一份字典，所以只要不是字体子集损坏的疑难文档，三库在文本正确性上拉不开差距。真正拉开差距的是下面这些"文本之外"的能力------毕竟翻译预处理的痛点从来不是"拿不到文字"，而是"拿不到结构"。
速度上 PyMuPDF 断层领先：30 页 0.042 秒，比 pdfplumber 快 18.6 倍。这意味着批量处理 500 份文档时，PyMuPDF 约 21 秒，pdfplumber 要 6.5 分钟。当然 pdfplumber 慢的代价换来了更细粒度的版面对象解析，见下文。
表格提取
| 库 | API | 检出表格数（30页） | 耗时 | 输出质量 |
|---|---|---|---|---|
| PyMuPDF | page.find_tables() |
30 | 0.797 s | 4行x3列，含表头 |
| pdfplumber | page.extract_tables() |
30 | 0.782 s | [['Region','Revenue','Growth'], ['EMEA','1.2M','8%'], ...] |
| pypdf | 无内置支持 | --- | --- | --- |
两者表格检出率相同（30/30），PyMuPDF 的 find_tables() 输出可直接调 .extract() 拿到二维列表；pdfplumber 的输出结构更"开箱即用"，直接就是嵌套列表。有意思的是两者表格提取耗时接近（都是对全部 30 页做表格检测），说明瓶颈在几何分析而非各自引擎。
pypdf 没有表格提取能力，这一局直接出局。
大文件扩展性测试（114 页）
把 30 页报告拼接成 114 页（约 146 KB / 16.4 万字符），模拟批量翻译的真实体量：
| 库 | 30 页耗时 | 114 页耗时 | 折算 500 页估计 |
|---|---|---|---|
| PyMuPDF | 0.042 s | 0.079 s | ~0.4 s |
| pypdf | 0.075 s | 0.303 s | ~1.5 s |
| pdfplumber | 0.780 s | 5.540 s | ~27 s |
114 页下 pdfplumber 比 PyMuPDF 慢约 70 倍，差距随页数进一步拉大（小文件上还只是 18 倍）。批量处理几百份文档的场景，这个差距是分钟级和秒级的区别。pypdf 的纯 Python 提取速度意外地不错，处在两者之间。
依赖与工程成本
| 库 | 安装体积 | 依赖链 | 版本迭代活跃度 |
|---|---|---|---|
| PyMuPDF | ~20 MB（含 MuPDF C 扩展） | 无额外依赖 | 高，且注意 1.24+ 推荐 import pymupdf |
| pdfplumber | 轻 | 依赖 pdfminer.six | 稳定 |
| pypdf | 极轻 | 纯 Python 零编译 | 稳定 |
工程上唯一要注意的坑是 PyMuPDF 的 API 变更：老代码里到处都是 import fitz，新版本会提示 deprecation，新项目统一用 import pymupdf，避免将来升级时全量替换。
词级坐标获取方式对比
翻译后重建版面（或做双语对照排版）必须有词级坐标，三库的获取代码：
python
# PyMuPDF：词级 8 元组 (x0, y0, x1, y1, word, block_no, line_no, word_no)
words = doc[0].get_text("words")
# 实测输出: (31.18, 30.20, 102.32, 52.23, 'Quarterly', 0, 0, 0)
# pdfplumber：词级字典，含 x0/x1/top/bottom
words = pdf.pages[0].extract_words()
# 额外还能拿到 chars / lines / rects / curves 等全部底层版面对象
# pypdf：无结构化坐标输出- PyMuPDF：8 元组含完整 bbox，够用；
- pdfplumber：字典形式 + 全量底层对象（字符级坐标、线条、矩形），版面分析深度是独门优势；
- pypdf ：只有
extract_text()，拿不到结构化坐标。
结论与选型建议
| 场景 | 推荐 | 理由 |
|---|---|---|
| 大批量文档翻译预处理 | PyMuPDF | 速度碾压，词级坐标齐全，表格也能提 |
| 需要精细版面分析（栏检测、字符级定位） | pdfplumber | chars/lines/rects 全量对象，解析最深 |
| 轻量脚本、零编译依赖环境 | pypdf | 纯 Python，装了就能跑，文本质量够用 |
再补充三个实测过程中确认的细节，选型时可能用得上：
其一，pdfplumber 的慢不是白慢的。 它底层用 pdfminer.six 把每个字符都解析成独立对象，所以能拿到字符级 bbox、线条、矩形这些"原材料"。做双栏检测、复杂嵌套表格这类深度版面分析时，只有它能给到足够细的原始数据。PyMuPDF 的解析是面向渲染优化的，粒度到词和块，一般场景够用，但字符级需求就到顶了。
其二，表格检测的算法路线不同但结果趋同。 PyMuPDF 的 find_tables() 和 pdfplumber 的 extract_tables() 在这份规整文档上检出率都是 30/30。但如果换成无线框表格（只有对齐空格没有边框线），两者都会退化，需要调参数（pdfplumber 的 text_strategy、PyMuPDF 的策略参数），这时候先拿小样本试参数再批量跑，别直接全量。
其三，pypdf 并非没有价值。 在受限环境（无法编译 C 扩展的服务器、AWS Lambda 这类）里，纯 Python 的 pypdf 是唯一选择，而且它的文本提取速度在 114 页测试中只比 PyMuPDF 慢 4 倍，作为"能跑就行"的兜底方案完全合格。
我的实际工作流是：批量环节用 PyMuPDF 做初筛和文本提取，遇到复杂版面（多栏、嵌套表格）再切 pdfplumber 精处理。两者互补而非替代。如果只能装一个库，翻译预处理场景选 PyMuPDF。
最后补一句务实的判断：这套对比的价值不在于"哪个库最强"，而在于把翻译预处理的验收标准定下来------文本完整、顺序正确、词级坐标可取、表格结构不散。三库横评只是手段。选型时先明确你的流水线在"版面重建"上走多深，再回头选库，比看任何 benchmark 都靠谱。
参考资料
- PyMuPDF 文档：https://pymupdf.readthedocs.io/
- pdfplumber 文档：https://github.com/jsvine/pdfplumber
- pypdf 文档：https://pypdf.readthedocs.io/
标签：PDF翻译、PyMuPDF、pdfplumber、pypdf、Python