这几年做文档处理和知识库项目我手上过过的 PDF 没有一万也有八千最头疼的从来不是“能不能打开 PDF”而是“PDF 里的内容到底怎么干净地变成能复用、能检索、能喂给大模型的文本”。早期用的方案要么是 PyPDF2 这类纯文本抽取遇到扫描件直接抓瞎要么是开一堆 OCR 工具凑合着做版面全乱表格变天书公式更是一塌糊涂。直到我接触了 MinerU 这个开源项目才发现“PDF 到 Markdown”这条路终于有一条走得通的捷径。这篇文章就围绕 MinerU 和它的核心工具 magic-pdf从 3.4.5 版本的实际使用经验出发把部署流程、命令行玩法、模型选择、常见坑点全部拆开讲清楚希望能帮正准备入手的你省掉一些不必要的折腾时间。1. MinerU 到底是什么从 magic-pdf 到 3.4.5 这条线1.1 PDF 解析的痛点为什么普通的“另存为”不够用很多人第一次处理 PDF 转文档时会困惑PDF 里明明能选中文字用 Word 或浏览器打开另存一下不就行了但实际上PDF 的核心设计理念是“固定版面”它保存的是文字、图片、矢量图形在页面上的绝对位置而不是像 HTML 或 Markdown 那样保留语义结构。这意味着即便是有文本层的 PDF你用普通方式抽取出来的也经常是段落顺序错乱、标题和正文混在一起、表格变成一堆散落的字符、公式变成内联符号根本没法直接使用。如果遇到的是扫描版或图片型 PDF情况更麻烦必须先过 OCR而传统 OCR 工具对排版结构基本没有概念识别完的文本就只是一坨从左到右、从上到下的字符流两栏论文会被读成横向穿插的乱序多级标题全部平级。这也是为什么“结构化文档解析”会成为知识库和 RAG 场景里的一个关键前置环节——你希望拿到的是“第 3 章的二级标题下有一张三行四列的表格表头是这些单元格内容是那些”而不是一整段无法对齐的原始文字。1.2 MinerU 的技术架构与 magic-pdf 的定位MinerU 是 OpenDataLab 开源的一个文档解析项目GitHub 仓库名是 opendatalab/MinerU它解决的问题正是上面说的“从任意 PDF 到干净 Markdown”这条链路。整个项目对外提供的核心 Python 包就叫 magic-pdf也就是说你在命令行里敲pip install magic-pdf装的就是 MinerU 的运行引擎而mineru命令则是新版统一的 CLI 入口。从技术架构上看MinerU 的解析流程是由几个模型协作完成的版面分析模型负责判断页面里哪些区域是标题、正文、表格、图片、页眉页脚OCR 模型负责识别扫描件里的文字公式识别模型单独处理行内公式和独立公式并把它们转成 LaTeX 格式最后还有一个管线把识别结果按阅读顺序重新拼接输出为 Markdown 文件同时把图片裁剪保存下来。比起“一个模型通吃所有任务”的端到端方案这种多模型流水线的设计优势在于每个环节都能针对性优化版面乱了可以只优化布局模型公式识别差了可以单独换模型权重排查问题的时候也更容易定位。1.3 3.4.5 版本带来了什么版本这块早期我接触 magic-pdf 的时候还是 2.x那时候安装依赖就踩了不少坑比如 torch 和 CUDA 版本不匹配、模型权重下载路径找不到之类。现在到了 3.4.5整体安装体验已经顺滑很多CLI 也统一成mineru开头不再有旧版magic-pdf命令和magic-pdf-json之类的一堆入口理解成本低了不少。3.4.5 这个版本在实际使用中我个人感受比较明显的几点变化是对扫描版 PDF 和图片型 PDF 的识别管线做了整合不再需要手动区分“纯文本型”和“扫描版”程序会自动判断输出目录结构更清晰中间结果比如 OCR 切块、版面框和最终 Markdown 分开放方便调试另外对 Windows 系统的兼容性明显变好了早期有些路径中文解析的问题在 3.4.5 里基本没有再碰到。当然版本迭代本来就快我这里讲的更多是我用下来的体验具体更新以官方 release notes 为准但整体方向是模型能力更强、安装部署更省心这也是我推荐大家直接上新版的原因。2. 本地部署实操Win11 环境下跑通 MinerU2.1 先看硬件CPU 还是 GPU内存怎么配部署 MiningU 之前第一步是先评估你的机器能跑什么配置。这个问题很现实因为 MinerU 的模型链路里既有传统的版面检测模型也有基于深度学习框架的 OCR 和公式识别模型它们的算力开销完全不是一个量级。我用一台配置比较普通的 Windows 11 笔记本Intel i5、16GB 内存、无独立显卡跑过 3.4.5单页 PDF 的解析时间大约在 10 到 30 秒之间遇到带大量图片和公式的论文页可能要 40 秒以上。如果文档只有十几页这个速度还能忍但一份 300 页的书或者动辄几十篇批量处理纯 CPU 模式会非常煎熬。所以我给的建议是如果你只是偶尔处理几份 PDFCPU 版本完全够用安装也简单如果你要做批量构建知识库、大量转换文档那至少要有一张 6GB 以上显存的 NVIDIA 显卡才能发挥 MinerU 的 GPU 加速能力。内存方面16GB 是及格线32GB 更稳。因为 MinerU 在处理过程中会同时把模型权重载入内存、缓存中间推理结果批量转换时如果并发数设置过高内存占用会快速上升。我自己在 16GB 内存的机器上用默认单线程处理没问题但一旦开了--workers 2加一批大文件内存就报警了。所以配置 worker 数时一定要结合内存实际量来不要贪多。2.2 Python 环境与依赖安装MinerU 3.4.5 对 Python 版本有要求我用的是 Python 3.10从官方的声明来看 3.10 是被重点测试的版本。如果你机器上同时装了多个 Python 版本强烈建议给 MinerU 单独建一个虚拟环境不要混在系统环境里不然以后升级别的包时很容易把依赖搞崩。Windows 11 下安装分两种路径纯 CPU 版和 GPU 版。纯 CPU 版最简单直接在虚拟环境里执行pip install magic-pdf[full]这条命令会拉取包括 PyTorch CPU 版在内的一整套依赖。如果你的 PyPI 源下载慢建议先配置镜像源比如用清华源或阿里源能省下大量等待时间。GPU 版会麻烦一点因为 PyTorch 的 CUDA 版本需要提前装好。我的建议是先装 CUDA 驱动和 cuDNN然后指定 CUDA 版本的 PyTorchpip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install magic-pdf[full]这里有个很容易踩的坑如果你先装了默认的pip install torch默认版本通常是不带 CUDA 支持或只支持 CPU 的后续跑 MinerU 时即使检测到显卡运算也依然走 CPU速度完全提不上来。所以 GPU 版一定要先确认torch.cuda.is_available()返回 True 再继续装其他依赖。装完可以快速验证一下python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU)输出里如果能看到显卡型号说明 PyTorch 的 GPU 支持已经就绪。另外在 Windows 11 上如果遇到缺少 Visual C Redistributable 的报错去微软官网装最新的 VC_redist.x64.exe 就能解决这属于比较典型的 Windows 环境问题和 MinerU 本身关系不大。2.3 模型参数文件准备两种常用方式MinerU 本身只是一个推理框架真正干活的是模型权重文件。安装完 magic-pdf 之后你还必须把模型权重下载到本地目录然后在配置里指定模型路径否则运行时会直接报错。模型文件可以在 Hugging Face 或 ModelScope 上找到。如果你的服务器或电脑在国内环境访问 Hugging Face 比较慢推荐优先使用 ModelScope也可以设置HF_ENDPOINT环境变量指向国内镜像站两种方式都能解决下载困难的问题。常用的下载方式是直接跑 MinerU 自带的下载命令mineru --download-models它会引导你选择下载来源然后自动拉取所有必需的模型权重。下载完成后模型会放在指定目录比如你手动设定的models-dir注意记下这个路径后面配置时要填。如果你的网络环境比较特殊部分模型总是下载失败也可以去 ModelScope 的模型页面手动下载某个模型文件然后按目录层级放好。模型文件不大总共大概几个 GB 的量级但网络不稳定时分包下载再手动放进去反而更可控。2.4 可视化界面验证先跑通一个 PDF部署完环境、下载好模型之后别急着写脚本先用一个测试 PDF 验证整条链路是否畅通。MinerU 3.4.5 自带 Web 界面模式跑起来之后可以在浏览器里上传 PDF 并直接查看解析结果这对新手非常友好因为可以第一时间看到每个环节的处理效果。启动 Web 界面很简单mineru --server默认会监听 8000 端口浏览器打开http://127.0.0.1:8000之后选择或上传一个 PDF稍等片刻就能看到解析出来的 Markdown 预览和版面对比效果。我第一次用这个界面测试时拿的是一份扫描版的中文技术手册里面有不少表格和代码块让我比较意外的是表格结构被完整保留成了 Markdown 表格语法代码块也单独成块没有中文乱码整体观感非常接近原文档排版。这一步的验证很有价值它能帮你区分“模型效果问题”和“环境配置问题”。如果页面能正常渲染、上传后能正常出结果说明环境管线基本没问题之后再做批量处理就只是在命令行的自动化层面了。3. 命令行批量转换实战从单文件到自动化处理3.1 从单文件到批量输出目录与文件结构可视化界面适合验证效果真正干批量活还得靠命令行。MinerU 3.4.5 的 CLI 设计比较简洁核心命令就是mineru加输入路径和输出目录例如mineru -p input.pdf -o output_dir第一次跑完记得看一下生成的文件结构。MinerU 不会只丢给你一个 Markdown 文件而是会生成一套包含中间结果和最终结果的完整目录output_dir/ ├── input/ │ ├── input.pdf # 原始 PDF自动复制 │ ├── input.png # 渲染后的页面位图中间结果 │ ├── input.json # 版面分析结果中间结果 │ ├── input_content_list.json # 结构化内容列表中间结果 │ └── images/ # 从 PDF 中抽取的图片 ├── input.md # 最终 Markdown 输出 ├── input_ocr.md # OCR 版本 Markdown如果启用了 OCR └── input_meta.json # 解析过程元信息我第一次看到这套结构的时候觉得“有点啰嗦”但后来发现非常实用input_content_list.json记录了每个元素的位置、类型、文字内容方便排查问题input_meta.json里包含了解析耗时、模型版本、各环节是否启用了 OCR 等元信息批量处理时写统计报表非常方便。这里要特别提醒在处理大量文件时中间文件尤其是 PNG 位图占用的磁盘空间是很大的一份 100 页的 PDF 渲染出来的 PNG 可能就有几百兆如果你只关心最终 Markdown建议跑完之后定期清理这些中间产物。3.2 核心命令行参数解读3.4.5 的参数项不算特别多但每一个都值得理解里头的逻辑因为它直接影响解析质量和运行资源。-p或--path输入文件或目录的路径。如果传目录MinerU 会遍历目录下的所有 PDF 文件如果传单文件就只处理一个。-o或--output输出目录路径。-m或--method解析方式常用的选择是auto、txt、ocr。默认的auto模式非常省心它会先判断页面是否有文本层有文本层的页面直接抽取没有文本层的页面自动走 OCR。txt模式则不管三七二十一全部只做文本层抽取速度快但扫描件会全空ocr模式则是全部强制走 OCR适合纯扫描版。这里我实际用下来的经验是auto对混合型文档一部分是文字层、一部分是扫描页效果最好耗时也适中但如果遇到版面特别复杂的情况auto的判断偶尔会把“有文字层但排版残缺的页面”误判为无需 OCR导致输出内容缺失这时候要改用ocr模式强制补救。--models-dir模型权重所在目录初始化时配置好一次后续基本不用动。--device运行设备填cpu或cuda。如果装了 GPU 版务必显式指定cuda因为这个参数不会因为你有显卡就默认启用。--workers并行 worker 数量。这是一个“收益递减且内存敏感”的参数我从 1 调到 4 的时候处理速度确实线性提升但内存占用也几乎线性上涨。16GB 内存的机器建议最多--workers 232GB 以上再考虑调到 4。--lang指定文档语言常用的是zh和en。如果你的文档以中文为主填zh可以提升 OCR 识别精度中英混排的文档填auto让它自动判断。这些参数配合起来用比如批量处理一批扫描版中文书籍可以这样写mineru -p ./books -o ./output -m ocr --device cuda --workers 4 --lang zh3.3 批量解析的 Python 封装脚本CLI 命令本身已经支持传入目录进行批量处理但真实业务里我们经常需要更强的控制比如跳过已经转换过的文件、异常自动重试、按时间戳归档输出等。这时候我会用 Python 直接调用命令行写一个外层调度脚本。下面是我在 Windows 11 上实测用的一个批量处理脚本核心思路是先扫描输入目录下所有 PDF 文件逐个执行mineru命令然后把输出归档到带时间戳的目录里同时记录日志方便排查import os import subprocess import sys from datetime import datetime from pathlib import Path def run_mineru(pdf_path: str, output_dir: str, method: str auto, device: str cuda, workers: int 2, lang: str auto, models_dir: str rD:\models\MinerU) - bool: cmd [ mineru, -p, pdf_path, -o, output_dir, -m, method, --device, device, --workers, str(workers), --lang, lang, --models-dir, models_dir, ] try: result subprocess.run(cmd, capture_outputTrue, textTrue, encodingutf-8, timeout600) if result.returncode 0: print(f[OK] {Path(pdf_path).name}) return True else: print(f[FAIL] {Path(pdf_path).name}: {result.stderr[-500:]}) return False except subprocess.TimeoutExpired: print(f[TIMEOUT] {Path(pdf_path).name}) return False def batch_process(input_root: str, output_root: str, **kwargs): input_root Path(input_root) output_root Path(output_root) pdf_files list(input_root.rglob(*.pdf)) total len(pdf_files) success 0 for idx, pdf_file in enumerate(pdf_files, 1): rel_dir pdf_file.parent.relative_to(input_root) out_dir output_root / rel_dir / pdf_file.stem out_dir.mkdir(parentsTrue, exist_okTrue) print(f[{idx}/{total}] Processing {pdf_file.name}) if run_mineru(str(pdf_file), str(out_dir), **kwargs): success 1 print(f\nFinished: {success}/{total} succeeded) return success if __name__ __main__: stamp datetime.now().strftime(%Y%m%d_%H%M%S) batch_process( input_rootrD:\docs\input_pdfs, output_rootrfD:\docs\output\{stamp}, methodauto, devicecuda, workers2, langauto, models_dirrD:\models\MinerU, )这个脚本有几个细节值得说明rglob(*.pdf)可以递归查找子目录里的 PDF适合按目录结构组织的文档库每次输出到独立的子目录里避免不同文件之间互相覆盖timeout600防止某个文件卡死导致整个批次停摆异常时打印 stderr 的最后 500 个字符方便快速定位失败原因。实测下来60 个文件、平均 20 页左右的技术文档集用 GPU 版跑完大概 25 分钟成功率 100%只有个别特别复杂的扫描页需要事后检查。如果你在 macOS 或 Linux 上跑逻辑一样只是路径写法不同。再提醒一次批量跑的时候把输出目录放在和输入目录不同的磁盘分区上能避免读写竞争导致的 IO 瓶颈这个小技巧在某些机器上能明显提速。4. 进阶玩法把 MinerU 接入自动化文档流水线4.1 RAG 场景里为什么要先用 MinerU 预处理现在做知识库问答和 RAG 的人越来越多但不少人一开始就直接把 PDF 切成 chunk 塞给向量库结果检索效果非常差。原因很简单向量化的是“纯文本”还是“乱序列”对检索质量的影响是决定性的。PDF 被硬切成分片后标题层级丢失、表格被拆散、公式变成乱码Embedding 模型拿到这种文本学习到的语义自然不准确。MinerU 的定位刚好弥补了这一环它在送入向量库之前先把 PDF 里的标题层级、段落、表格、公式、图片关系全部结构化输出一份干净的 Markdown。后续不管你是用 LangChain 自带的 MarkdownHeaderTextSplitter 按标题切分还是用其他切片器做语义切分都能在这个干净结构的基础上工作。所以我的建议是RAG 预处理链路的第一个环节就应该接一个 MinerU 这样的结构化解析器再做切片和向量化效果会比直接在原始文本上操作好很多。4.2 基于 FastAPI 封装一个转换服务如果你有多个业务方或团队内部很多成员都要用到 MinerU每次都在命令行里手动跑显然不行。这时候可以把 MinerU 封装成一个 HTTP 服务统一接收 PDF统一出 Markdown方便集成到其他系统中。封装思路很简单用 FastAPI 写一个上传接口接收 PDF 文件保存到临时目录调用 MinerU 命令行转换然后把 Markdown 和图片压缩成 zip 返回给用户。需要注意的关键点是并发控制和任务队列。MinerU 推理很吃资源如果同时来 5 个请求全部并发转换16GB 内存机器大概率直接崩。所以服务端要限制同时只有 1 到 2 个转换任务在跑其他请求排队等待。我提供一个最简示例核心逻辑是加一个全局并发锁和一个任务队列import asyncio import uuid import zipfile from pathlib import Path from fastapi import FastAPI, UploadFile, File from fastapi.responses import FileResponse import subprocess app FastAPI(titleMinerU Convert Service) semaphore asyncio.Semaphore(2) # 最多同时跑 2 个转换任务 async def run_conversion(pdf_path: Path, output_dir: Path): cmd [ mineru, -p, str(pdf_path), -o, str(output_dir), -m, auto, --device, cuda, --workers, 1 ] proc await asyncio.create_subprocess_exec( *cmd, stdoutasyncio.subprocess.PIPE, stderrasyncio.subprocess.PIPE, ) _, stderr await proc.communicate() if proc.returncode ! 0: raise RuntimeError(fConversion failed: {stderr.decode(errorsignore)[-500:]}) app.post(/convert) async def convert_pdf(file: UploadFile File(...)): task_id uuid.uuid4().hex work_dir Path(f./tmp/{task_id}) work_dir.mkdir(parentsTrue, exist_okTrue) pdf_path work_dir / input.pdf pdf_path.write_bytes(await file.read()) async with semaphore: await run_conversion(pdf_path, work_dir) # 打包 Markdown 和图片 zip_path work_dir / result.zip with zipfile.ZipFile(zip_path, w) as zf: for f in work_dir.rglob(*.md): zf.write(f, f.name) images_dir work_dir / images if images_dir.exists(): for img in images_dir.iterdir(): zf.write(img, fimages/{img.name}) return FileResponse(zip_path, filenamef{Path(file.filename).stem}.zip) # 生产环境不要把临时目录放在 /tmp 下且需要定期清理这段代码的核心价值不是“能转 PDF”而是给出了一个可落地的服务化思路用信号量控制并发、用 task_id 隔离每个请求的工作目录、把中间产物打包成 zip 返回。生产环境里你还得加上任务队列比如 Celery和存储层但基本骨架就是这个。4.3 在 Dify 里调用 MinerU 的一种低代码思路不少人提到 Dify 本地调用 MinerU其实这不是一个开箱即用的官方集成而需要你自己做桥接。我的做法是先按 4.2 的方式部署一个 MinerU HTTP 服务然后在 Dify 的自定义工具或工作流里写一个 HTTP 请求节点上传 PDF 并接收返回的 zip再解压 Markdown 内容继续后续的切片和 Embedding。具体到配置上Dify 的 HTTP 请求节点支持 multipart/form-data 文件上传把 PDF 作为file字段传过去响应接收的是 zip 二进制流你需要用代码节点解压并解析出里面的 Markdown 文本。这听起来绕但好处也非常明显Dify 的文档处理流程和问答逻辑可以完全复用MinerU 只作为一个独立的文档预处理服务被外部调用升级模型时不用动 Dify维护成本低。这里分享一个我在实际配置中遇到的坑Dify 的 HTTP 节点默认超时时间一般只有几十秒而 MinerU 转一个几十页的扫描版 PDF 可能要几分钟直接用在“对话中实时转换”的场景会超时。稳妥的做法是提前用异步任务预处理好文档把转好的 Markdown 存到本地或向量库里不要在用户的对话请求里实时触发转换。换句话说MinerU 更适合放在“文档入库”阶段而不是“查询回答”阶段。5. 我踩过的坑与常见报错速查5.1 模型下载失败的几种原因我在初次部署时最常遇到的就是模型下载问题。MinerU 初始化模型时如果网络不稳定或访问境外站点速度过慢很容易出现某个模型文件一直拉取失败之后整个程序反复重试也无果。这类问题的解决思路是“分开下载逐个校验”。优先用 ModelScope 渠道或者提前手动把模型文件下载好放到对应目录再启动程序。MinerU 的模型目录结构是固定的你在初始化时指定models-dir之后程序会在该目录下按固定层级寻找模型文件。如果你是从别处拷贝模型目录注意保持完整的目录结构不要只拷贝部分文件否则还是会报“model not found”之类的错误。排查的时候可以先打开调试日志mineru -p test.pdf -o out --verbose日志里会明确写出当前加载了哪个模型、哪个文件缺失、哪个文件加载失败基本能一步定位。5.2 转换结果为什么“缺字漏字”很多人第一次跑完发现 Markdown 里出现大面积缺字漏字第一反应是 MinerU 效果不行。其实大多数情况下这是“模式选择不当”造成的。如果你的 PDF 是扫描版的但默认的auto模式把某些页面误判为文字层页面直接从 PDF 里抽文字而扫描件的“文字层”其实是一层透明的、位置错乱的隐藏文字抽取结果自然是乱的。此时要强制使用ocr模式处理那批扫描文件保证每个页面都走 OCR 识别。反过来如果 PDF 是正常文字版你却用了ocr模式强制 OCR反而可能因为图像渲染清晰度不足导致识别错误。所以合理做法是对文档类型做分类扫描版统一走ocr文字版统一走auto或txt不要把两类文档混在一个命令里处理。另外中文字体缺失也可能导致输出中的中文变成问号或乱码这种在 Windows 上不太常见但在精简版 Linux 容器里容易碰到。解决方法是安装完整的中文字体包比如fonts-noto-cjk然后重新跑一遍。5.3 速度和内存问题怎么排查批量处理时速度慢和内存爆掉是最常见的问题。先说速度GPU 版如果感觉没有明显加速先执行python -c import torch; print(torch.cuda.is_available())确认 PyTorch 是否真的在用 CUDA同时确认命令行里的--device cuda参数是否传了参数没传的话即使你的环境支持 GPUMinerU 也会默认跑 CPU。内存爆掉的问题往往出在并行 worker 数上尤其是--workers 4配合大文件时每个 worker 都会加载一份模型副本内存直接翻几倍。我的经验值是16GB 内存跑--workers 2就必须留意系统资源了如果单文件本身就超过 100 页建议直接把workers设为 1让一个进程吃满显存而不是同时开多个进程互相抢资源这样速度反而更稳。5.4 常见报错速查表整理一个我在 Windows 11 上频繁遇到的报错对照表基本覆盖了大部分环境层面的问题报错信息常见原因解决思路ModuleNotFoundError: No module named magic_pdf没有正确安装依赖在激活的虚拟环境里执行pip install magic-pdf[full]FileNotFoundError: model config not found模型权重缺失检查models-dir路径是否配置正确模型目录结构是否完整Illegal instruction或程序直接闪退CPU 指令集不兼容常见于老旧 CPU 跑新版 PyTorch建议换 GPU 或旧版 torchCUDA out of memory显存不足降低批量并发、改用单页处理或换更大显存显卡输出中文全是?字体缺失Windows 安装中文字体包Linux 安装fonts-noto-cjk输出 Markdown 里表格错乱版面复杂表格识别失败尝试ocr模式强制重解析或在后续做表格结构二次修复Web 界面打不开端口被占用换端口启动如mineru --server --port 8001这张表不能覆盖所有场景但排查思路可以复用先看日志输出了什么模型加载信息再看是环境问题还是模型问题最后再考虑是不是文档本身的特殊情况。90% 的问题都能在这三步内定位。6. 写在最后我自己用下来的几点体会MinerU 和 magic-pdf 这套工具链实际用下来最大的感受是“它在试图解决一个足够难的问题而且解决得确实不错”。PDF 转 Markdown 看起来是一个简单需求但真正要把版面、表格、公式、图片都还原到位背后是模型、工程、产品三方面的反复打磨能做到这个程度开源项目的诚意是看得见的。如果你要开始用我的建议是先拿几份你手头最典型的文档跑一遍用可视化界面看看效果找到最适合你文档类型的method参数再写批量脚本。不要一开始就追求全自动流水线而是先把单文件的输出质量调到满意再逐步加并发、加队列、加服务化封装。另外3.4.5 这个版本已经比较稳定但开源项目迭代快升级前先看看 release notes测试数据里有没有破坏性变更再决定是否升级。最后分享一个小技巧MinerU 的中间 JSON 文件其实藏着很多有价值的结构化信息比如每个标题所在的页数和坐标。如果你在做文档级的知识管理或学术文献分析可以尝试直接解析这些 JSON而不是只盯着 Markdown 用。很多二次开发的可能性都藏在这层“看似多余”的中间结果里。