夜雨聆风做文档处理的人，多半撞见过一件挺拧巴的事。一份 PDF 落在手里，鼠标一划，字明明能选中复制，可你的流水线还是把它一页页转成图片，丢给 OCR，等它慢慢吐结果，再按页付一次钱。绕一大圈，识别回来的字，未必比直接复制粘贴准。
这毛病不是个例。Firecrawl 统计过，大约 54% 的 PDF 本身就带着完整的文本层。 报告、论文、发票、合同，字早就在文件里躺着，根本用不着拿识别去猜图像。可很多团队的处理方式，管你有没有文本层，一股脑全扔给 OCR。
于是又慢又贵。云识别按页收费，量一大，这钱哗哗地流。
Firecrawl 最近开源了个 Rust 库，叫 pdf-inspector，专治这个毛病。 上线几周，GitHub 上已经有 13.7K 的星标啦。我把它的仓库翻了一遍，又对着官方那批基准数字看了半天，觉得值得讲一讲，它到底怎么用，能替你拦下哪部分白花的钱。
最值钱的一点：几十毫秒精准分类
先说我看到的最值钱的一点。它拿一份 PDF，先花几十毫秒判断这文件是什么类型，再决定怎么收拾。类型分四类：
• TextBased，文字版。 文字能直接选中复制，这类就在本地提取，转成 Markdown。 • Scanned，扫描版。 纸本扫出来的 PDF，需要 OCR。 • ImageBased，图片型。 内容基本由图片构成，交给 OCR 或视觉模型。 • Mixed，混合型。 一部分页面有字，一部分是扫描图。文字页本地解析，其余送 OCR。
除了类型，它还返回一个 0 到 1 的置信度分数，外加一份 pages_needing_ocr 的页码清单。哪几页要识别，直接列给你，不用自己猜。
这个判断值钱在哪。 拿一份 210 页的财报来说，只有 60 页是扫描件。老办法，210 页全送 OCR。让它在前面拦一道，只有那 60 页走识别，剩下 150 页本地直接提取。省下来的，除了时间，还有实打实的钱。
技术内核：不渲染，直接读结构，10～50 毫秒搞定
它怎么做到 10 到 50 毫秒就分类。不碰渲染，直接读 PDF 的内部结构。没有渲染，就没有模型推理，三百页往上的大文件照样毫秒级。
流程大致是这样：
1. 解析 PDF 的 xref 表和页面树，不全量加载对象。 2. 按策略挑要检查的页面。 3. 在内容流里找文本操作符 Tj/TJ和图片操作符Do。4. 根据抽样页里有没有文本操作符，给出分类。
官方给了四种扫描策略：
• EarlyExit，默认。 扫全部页面，遇到第一个非文字页就停，适合快速分流。 • Full。 全扫，不提前退出，适合精确区分混合型和纯扫描。 • Sample(n)。 抽样 n 页，超大文件用，速度优先。 • Pages(vec)。 只看指定页面，调用方本来就清楚要检查哪些页时用。
怎么用？支持全栈，一行命令就能上手
pdf-inspector 覆盖了主流开发场景——CLI、Python、Node.js、浏览器（WASM）、Rust 全都有。最省事的方式是直接装命令行工具，几秒钟就能跑起来。
CLI 快速上手
cargo install pdf-inspector # 安装pdf2md document.pdf # 转 Markdownpdf2md document.pdf --json # JSON 输出，方便管道detect-pdf document.pdf # 只检测分类，不提取内容detect-pdf document.pdf --analyze --json # 顺便做布局分析（表格/列）常用参数还有 --select-pages 指定页面，--pages 插入分页标记，--compact 精简输出等，一个命令就能应对绝大多数场景。
其他语言同样简单
• Python： pip install maturin后编译，代码里import pdf_inspector直接调用process_pdf()。• Node.js： npm install @firecrawl/pdf-inspector，导入后processPdf()即可。• 浏览器：用 WASM 版 @firecrawl/pdf-inspector-wasm，PDF 在本地处理，数据不上服务器。• Rust： cargo add pdf-inspector，最原生，性能最佳。
所有接入方式均全程本地运行，不联网、不依赖 GPU，隐私和速度都有保障。
文本提取与 Markdown 转换：位置感知、表格检测、中文支持
分类只是第一步。它的文本提取和 Markdown 转换，同样值得一说。
• 位置感知提取。提取时保留字体信息和 X/Y 坐标，自动识别多栏。双栏排版的论文、报纸，按先左栏上到下、再右栏上到下的顺序输出，不会左右栏串着读。 • Markdown 转换。标题层级按字体大小自动认 H1 到 H4，列表、代码块、表格、粗体斜体、URL 链接都能转。代码块靠等宽字体识别。 • 表格检测走双模式。一是从 PDF 绘图操作里做矩形检测，二是从文本对齐做启发式。财务报表、跨页表格、带脚注的表格都能碰。 • CID 字体支持（对中文 PDF 极其要紧）。它走 ToUnicode CMap 解码，能处理 Type0/Identity-H 字体和 UTF-16BE、UTF-8、Latin-1 编码。国内很多导出的 PDF 用 Identity-H 编码，没有 ToUnicode CMap，提取出来全是乱码。做中文文档的人，大概都懂这个疼。
性能实测：总分第一，速度比竞品快 30 倍以上
性能拿数据说话。官方在 opendataloader-bench 语料库（200 份 PDF）上做了基准测试，2026 年 7 月 31 日在 Apple M4 Pro 上重跑。
| pdf-inspector | 0.875 | 0.915 | 0.814 | 0.470s | |
| 0.811 | |||||
总分、阅读顺序、表格三项全部领先。速度上，比 PyMuPDF4LLM 快 36 倍，比 MarkItDown 快 34 倍。
单份文字型 PDF，本地处理能控制在 200 毫秒以内。Firecrawl 自己的 Fire-PDF 引擎用上这套方案后，整体解析速度提升了 3.5 到 5.7 倍，平均每页不到 400 毫秒。
资源占用与成本节省：轻量、本地、省钱
算力要求很轻。纯 Rust 实现，没有 ML 模型，没有外部服务调用，唯一依赖是一个叫 lopdf 的 PDF 解析库。普通开发机、服务器，连树莓派都能流畅跑。内存方面，文档只加载一次，检测和提取共享同一份加载结果，处理几百页的 PDF，占用通常几十到几百 MB。全程本地运行，不联网，GPU 也不需要。
算力上真正烧钱的地方，在云识别账单。 传统做法是把所有 PDF 都送去 OCR，每页都要付费。pdf-inspector 帮你把 54% 不需要 OCR 的拦下来本地处理，只把真正要识别的扫描页送出去。日处理上万份 PDF 的团队，省下的识别费相当可观。
它不内置 OCR。碰到扫描件、坏字体编码、结构特别诡异的 PDF，还是得备一条后备识别链路。但它会主动标记编码异常和需要 OCR 的页面，不会静悄悄吐一堆乱码。
建议的用法是，先跑 detect 分类，文字版直接本地解析转 Markdown，扫描页再按需调 OCR。把它放在 RAG 入库链路最前面，用来砍掉那批根本不需要跑识别的请求，协议是 MIT，可以商用。
AI 应用、RAG 系统、知识库越铺越广，文档处理成本正变成很多团队的隐形开销。花 20 毫秒问一句“这份需要 OCR 吗”，比直接花 5 秒去识别，划算太多。 仓库在 github.com/firecrawl/pdf-inspector，正在跑文档处理的，不妨装进流程试一试，说不定下个月的识别账单能瘦一圈。
