处理 PDF 文件是 AI 应用的常见场景：RAG 知识库需要从 PDF 中提取文本，文档分析需要判断 PDF 是文本型还是扫描件。传统方案要么用 PyMuPDF（慢），要么用 OCR 服务（贵且慢）。

Firecrawl 团队开源了 pdf-inspector——一个用 Rust 写的 PDF 分类和文本提取库。15K 星，MIT 协议。核心卖点：纯本地运行，200 篇 PDF 解析不到半秒，无需 OCR。

Benchmark：0.875 综合分，0.47 秒跑完 200 篇

在 opendataloader-bench 语料库（200 篇 PDF）上的测试结果：

• pdf-inspector: 综合 0.875 | 阅读顺序 0.915 | 表格 0.814 | 标题 0.788 | 速度 0.47s

• liteparse: 综合 0.873 | 阅读顺序 0.913 | 表格 0.693 | 速度 0.75s

• opendataloader: 综合 0.831 | 表格 0.489 | 速度 2.57s

• pymupdf4llm: 综合 0.735 | 表格 0.401 | 速度 17.12s

• markitdown: 综合 0.589 | 表格 0.273 | 速度 16.17s

综合分最高、速度最快。比 PyMuPDF4LLM 快 36 倍，比 MarkItDown 快 34 倍。测试环境 Apple M4 Pro，2026 年 7 月 31 日。

智能分类：10-50ms 判断是否需要 OCR

这是最有工程价值的功能。pdf-inspector 能在毫秒级判断一篇 PDF 是文本型（TextBased）、扫描件（Scanned）、纯图片（ImageBased）还是混合型（Mixed）。通过采样内容流中的文本算子和图片算子来实现，不需要加载完整文档。

为什么重要？因为大约 54% 的 PDF 本身就有文本层，不需要走 OCR。在批处理管道中，先用 pdf-inspector 分类（约 20ms），文本型 PDF 直接本地提取（约 150ms），扫描件才送 OCR 服务（2-10 秒）。这省掉了大量不必要的 OCR 调用成本和延迟。结果还包含 pages_needing_ocr——按页标记哪些需要 OCR，支持逐页路由而不是全量 OCR。

文本提取和 Markdown 转换

位置感知的文本提取：带字体信息、X/Y 坐标、自动多列阅读顺序。转换成 Markdown 时支持：

• 标题 H1-H4：基于字号比例检测，0.5pt 聚类

• 列表：项目符号、数字编号、字母编号

• 代码块：等宽字体检测（Courier、Consolas、JetBrains Mono 等）

• 表格：双模式——矩形检测（PDF 绘图操作）+ 启发式检测（文本对齐）

• 加粗/斜体、URL 链接、下标/上标

• 多列布局自动检测、RTL 文本支持

• CID 字体解码（Type0/Identity-H）、UTF-16BE/UTF-8/Latin-1

文档只加载一次，检测和提取共享同一份解析结果，避免重复 I/O。

多语言绑定 + 浏览器 WASM

除了 Rust 原生 API，还提供三种绑定：

Python: pip install pdf-inspector，pdf_inspector.process_pdf("doc.pdf")

Node.js: npm install @firecrawl/pdf-inspector

浏览器 WASM: npm install @firecrawl/pdf-inspector-wasm——在浏览器和 Web Worker 中本地运行同一个 Rust 解析器，无需服务端往返

还有 CLI 工具 pdf2md 和 detect-pdf，支持 JSON 输出、指定页码、布局分析等参数。

适用场景和局限

适合：原生文本 PDF——报告、论文、财务文档、发票、法律文件。需要速度、阅读顺序和表格结构的场景。

局限：扫描件仍需 OCR。它是 OCR 的前置分类器而非替代品。纯 Rust，唯一外部依赖是 lpodf（PDF 解析库）。无 ML 模型，无外部服务。对于需要处理大量 PDF 的 AI 应用——RAG 知识库、文档智能处理——这个分类+提取的组合拳能显著降低成本。