workbuddy 并非自研 pdf 解析工具，而是封装 pdfplumber、pymupdf 等底层库；解析效果取决于所调用库、参数配置（如表格策略、ocr支持、字体编码处理）及内存管理方式。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 并不是一个广为人知的开源或主流 PDF 解析工具，也没有公开的、被广泛验证的 PDF 解析 SDK 或 CLI 工具与其强绑定。如果你在某个内部系统、低代码平台或特定企业级工作流中看到 WorkBuddy 调用 PDF 解析能力，大概率是它封装了底层库（如 pdfplumber、PyMuPDF、pdfminer.six 或商业 API），而非自研解析引擎。
这意味着：你无法脱离其运行环境单独评估 “WorkBuddy 的 PDF 解析能力”，而必须看它实际调用了什么、传了什么参数、如何处理异常。
排查 WorkBuddy 解析失败时，先确认它背后的真实解析器
- 查看日志里是否出现
pdfplumber、fitz（PyMuPDF）、PDFTextExtractionError等关键词 - 如果是 Web 端调用，抓包看请求发往哪个后端接口，再查该服务依赖的 Python/Java 库
- 若文档含扫描件（纯图片 PDF），
WorkBuddy自身不带 OCR 功能，此时解析为空是正常现象，不是 bug
表格提取经常错位？大概率是用了 pdfplumber 默认设置
pdfplumber 对复杂表格（合并单元格、无边框、斜线表头）容忍度低，且默认不启用 vertical_strategy="lines" 或 horizontal_strategy="lines"：
使用 draw.io（.drawio 格式）和 SVG 生成兼容 Microsoft Visio 的架构图。当用户需要以下任一场景时触发： - 用于 Visio 或技术文档的架构/系统/网络图 - 带连接标注的分层控制系统图 - 将 draw.io XML 转换为稳定、可嵌入的 SVG - 修复 Visio 或 draw.io 无法打开的故障排查类图表 - 任何需专业级布局且文本可编辑的图表
- 表格识别前建议显式配置
table_settings={"vertical_strategy": "text", "horizontal_strategy": "text"}，再根据效果切换为"lines"或"explicit" - 含多栏排版的 PDF（如双栏论文），需先用
page.crop(...)分区域提取，否则列内容会混在一起 -
workbuddy若未暴露这些参数入口，就只能预处理 PDF（例如用fitz.Page.get_text("blocks")先做区块切分）
中文乱码或漏字？检查字体映射与编码回退逻辑
PDF 中文字体常以 CID 编码嵌入，解析器若没加载对应 ToUnicode CMap，就会输出乱码或空字符串：
-
pdfplumber依赖fonttools和内置映射表，对非标准 GBK/UTF-16 字体支持弱 -
PyMuPDF（fitz）表现更稳，可强制用page.get_text("text", encoding="utf-8")，但需确保 PDF 内嵌字体支持 Unicode - 如果
WorkBuddy返回的文本中中文全变成方块或问号，基本可判定它调用的是未开启 Unicode 支持的旧版pdfminer
大文件卡死或内存爆掉？别怪 WorkBuddy，先看它用的解析器是否流式处理
-
pdfplumber和pdfminer.six都是页级加载，1000 页 PDF 会一次性解压所有资源到内存 -
PyMuPDF支持懒加载，可用doc[page_num].get_text()单页处理，适合分批调度 - 如果
WorkBuddy的任务超时或 OOM，优先确认它是否做了页循环 + 显式del page/gc.collect()，而不是把整个pdfplumber.PDF对象长期持有
真正影响解析效果的，从来不是 WorkBuddy 这个名字，而是它背后那几行调用 fitz 或 pdfplumber 的代码 —— 以及有没有人愿意为每类 PDF 样式写适配逻辑。
