Spring Boot + Apache Tika：文档解析不是 parse 一下就完了

Spring Boot 接入 Apache Tika 的 demo 很简单：加依赖、建配置、上传文件、调用 parse。问题是，真实系统里的文档不会都像 demo 文件那样干净。PDF 可能很大，Word 可能损坏，图片型文档可能没有文字层，表格可能乱掉，用户也可能上传不该处理的文件。一个能上线的文档系统，关注的从来不只是“能不能 parse 出文本”，而是“解析后怎么存、怎么查、怎么回滚、怎么解释失败”。

把 Tika 放在系统入口，而不是业务角落

更稳的做法，是把文档解析当成一条 ingestion 管道。上传之后先做文件大小、MIME、扩展名、页数上限和安全检查，再进入队列异步解析。解析结果、元数据、错误原因、parser 版本和原文件位置都要保存下来，方便追查。这样以后用户问“为什么这份 PDF 搜不到”，你不是在猜，而是能回头看整条处理链。

不要让请求线程承担重活

大文档解析很容易超过用户请求能接受的时间。接口最好返回任务 ID，前端轮询或订阅状态。这样即使解析失败，也能明确告诉用户是超时、格式不支持、内容为空，还是需要 OCR。更重要的是，异步化之后你才能给解析任务单独设置超时、重试和并发上限，而不会把整个 Web 服务拖慢。

一个更现实的实现顺序

可以先用 Tika 做文件类型识别和基础文本提取，再根据文档类型决定后续处理：普通文本直接切块，扫描件走 OCR，表格密集型文档做额外清洗，权限敏感的文档保留访问控制标签。下面这类思路比“只调用一次 parse”更接近生产：

上传校验 → 入队 → 识别 MIME/内容类型 → 限制解析时间和大小 → 提取元数据与正文 → 清洗页眉页脚/水印/空行 → 分块索引 → 记录失败原因与版本

进入搜索和 RAG 前还要清洗

Tika 输出的文本只是初稿。页眉页脚、页码、重复水印、表格错位、空白行都可能污染搜索结果。要做企业搜索或 RAG，应该继续做分段、去噪、权限绑定和引用来源保存。对于扫描件，OCR 结果也要单独标记来源和置信度，避免把错字直接当成事实。

生产接入清单

• 限制文件大小、页数、解析时间和可接受格式。
• 异步执行解析任务，记录状态和失败原因。
• 保存原文件、提取文本、metadata、parser 版本。
• 对扫描件准备 OCR 后备链路，并隔离临时文件目录。
• 对进入知识库的内容做清洗、分块和权限控制。

Tika 是很好的统一入口，但它不是万能 parser。把它当工具类用，只能完成 demo；把它当文档管道边界设计，才适合放进生产系统。