Python PDF 处理的 PyMuPDF vs pdfplumber

pdfplumber 表格识别准但大文件易卡顿，pymupdf 速度快且支持编辑但中文和表格识别弱；应按页类型分路径处理：pdfplumber 专攻表格页，pymupdf 处理文字、图片及编辑操作。

pdfplumber 读表格很准，但打开大文件卡死

pdfplumber 的核心优势是基于字符位置做文本布局分析，对扫描件不敏感，但对纯文本 PDF 的表格识别准确率明显高于 PyMuPDF。它默认用 pdfminer.six 解析，会把整页内容加载进内存再切分，遇到 100+ 页、带大量矢量图或嵌入字体的 PDF，pdfplumber.open() 可能卡住十几秒甚至抛出 MemoryError。

实操建议：

• 只读取需要的页：用 pages=[0, 5, 10] 参数限制范围，别调 pages=None（默认全读）
• 关掉冗余解析：加 laparams={"all_texts": False}，避免构建文本框树形结构
• 大文件优先换 PyMuPDF 提取文本，再用 pdfplumber 单独抠某一页表格

PyMuPDF 支持直接改 PDF，pdfplumber 纯读取

PyMuPDF（fitz）本质是 PDF 渲染引擎封装，能增删页、涂鸦、加水印、合并、加密——所有操作都在原文件二进制层面生效；pdfplumber 完全没写能力，连保存为新 PDF 都做不到。

常见错误现象：有人试图用 pdfplumber.Page.to_image() 后调 .save()，结果发现返回的是 PIL.Image 对象，不是 PDF 页面，根本没法回写。

立即学习“Python免费学习笔记（深入）”；

实操建议：

• 要加页眉页脚或高亮关键词：用 fitz.Page.add_text_annot() 或 Page.insert_pdf()
• 想从 pdfplumber 拿到坐标再用 PyMuPDF 标注？注意坐标系差异：pdfplumber y 轴向下为正，fitz 向上为正，得用 page.rect.height - y 反转
• 批量打水印场景，别先用 pdfplumber 提取文字再判断——直接用 fitz.Page.search_for("机密") 更快

中文乱码时，PyMuPDF 要手动指定字体，pdfplumber 通常自动 fallback

PyMuPDF 默认只认基础 14 字体（如 Helvetica），遇到嵌入的中文字体（如 NotoSansCJKsc-Regular）或子集化字体，page.get_text("text") 返回空字符串或方块。pdfplumber 底层用 pdfminer，对 CID 字体和 ToUnicode CMap 支持更稳，多数情况无需干预。

实操建议：

• PyMuPDF 中强制用系统字体渲染：传参 page.get_text("text", fontname="simhei")（需提前确认该字体已安装）
• 更可靠的做法是用 page.get_text("dict") 拿原始字形信息，检查 block["type"] == 0（文本块）和 span["font"] 字段，定位异常字体名
• pdfplumber 中若仍乱码，检查 PDF 是否真包含文字——用 pdftotext -layout input.pdf - 命令验证，返回空说明是扫描件

提取速度差 3–5 倍，但“快”不等于“对”

PyMuPDF 解析单页平均 5–20ms，pdfplumber 同样页面常要 80–200ms，差距来自后者要做字符聚类、线检测、表格线匹配。但如果你要的是「每行首尾对齐的业务数据」，PyMuPDF 的 get_text("text") 可能把标题和正文挤在同一行，而 pdfplumber 的 page.extract_table() 能区分出表头与数据行。

性能陷阱：

• 别在循环里反复调 pdfplumber.open()——它每次都要解压对象流，开销远大于解析本身
• PyMuPDF 的 page.get_text("blocks") 比 "text" 慢一倍，但结构更清晰，适合后续做规则提取
• 混合内容（文字+表格+图片）PDF，建议分路径处理：PyMuPDF 提取图片和页码，pdfplumber 专攻表格页

真正难的不是选哪个库，而是同一份 PDF 里不同页类型不一致——比如前 3 页是报告文字，中间 5 页是财务表格，最后 2 页是签名扫描件。这时候硬套一个库，不如按页分类再 dispatch。