1. 需求拆解：为什么“PDF 转表格”总是翻车
先说个现实：很多 Java 工程师一碰到 PDF 表格提取就头大。PDF 这格式天生就不是给人编辑的，它保存的是“坐标和图形”，不是“行和列”。你用鼠标在 PDF 里看着是整整齐齐的表格，复制出来全乱了，要么挤成一堆空格，要么直接串行。这个问题的根源在于，PDF 内部有三种“伪表格”形态：有真实边框线的表格、靠对齐排版形成的视觉表格、以及图片型表格。不同形态对应完全不同的提取策略，没有一套代码能通吃。
我们这次要解决的问题，是把各种形态的 PDF 表格自动提取成 Excel 或 CSV。它能解决的场景很明确：财务对账单、政府公告附件、论文数据表、产品参数手册、老系统的导出报表。这些文档少则几百页，多则几万页，人工录入既不现实也容易出错。自动化提取的价值不只是省时间，更重要的是把数据接入后续的入库、分析、可视化流程，让原本“躺在 PDF 里”的数据真正流动起来。
这篇文章适合的读者，是已经会用 Java 写基本 CRUD、但没系统接触过文档解析的开发者。我会从工具选型、原理解析、完整代码、坑点排查四个层面展开，最后给出一套可以直接抄作业的方案。如果你是刚入门的小白，建议先把 Java 基础和 Maven 依赖搞明白再来看；如果你已经踩过 PDF 解析的坑，那直接看第 3 章的姿势比对和第 4 章的问题清单，应该能找到你想要的答案。
2. 工具选型：四大主流方案横向对比
2.1 从 PDFBox 手写到 Tabula 一键识别
先盘一下目前 Java 生态里能干这活的库，我按从底层到上层的顺序列：
Apache PDFBox：最底层的 PDF 解析库，能读文本、能画页面、能提取原始内容流，但表格识别基本靠手写坐标逻辑。它的
PDFTextStripper只能按页面顺序抽文本，表格到你手上就是一堆带着奇怪换行符的字符串。优点是完全免费开源、可定制性极强，缺点是开发成本高到离谱。Apache POI：这是处理 Excel 的库，不直接解析 PDF，但把提取结果写入
.xlsx时离不开它。POI 有两个 API：HSSF管老版.xls，XSSF管新版.xlsx，现在还有个SXSSF处理海量数据。配合 Tabula 出的结果正好用。Tabula-Java：表格识别的利器，它经历了“命令行工具 → 网页版 → Java 库”的演进。
tabula-java把 PDF 页面当成一张坐标网，算法会去检测页面上的垂直线和水平线，然后推断单元格边界。支持输出Table对象列表，每个Table有行有列，再配合 POI 写 Excel 非常顺手。这个库是我们这次的主角。FastCSV / OpenCSV：写 CSV 的轻量选手。如果目标文件是 CSV 而不是 Excel，直接用它把提取出来的行数据拼字符串就行。FastCSV 性能猛，OpenCSV 生态老、文档多，二选一不会错。
还有一个常见的iText，它的pdf2Data模块确实能玩出花活，但新版 iText 许可证查得很严，一不小心就碰商用授权红线，所以不在这次推荐范围内。开源、无商业风险、社区活跃，这三个条件筛完之后，最稳的组合就是Tabula + POI + FastCSV。
2.2 为什么最终选择 Tabula-Java
选择 Tabula-Java，不是因为它功能最全，而是它在“识别率”和“使用成本”之间取得了最好的平衡。网上有人拿它跟 pdfplumber（Python 生态）对比，结论是英文规则表格 Tabula 不输，中文无边框表格两方都吃力——但这不等于不能用，我们后面会讲怎么补齐这个短板。
Tabula-Java 的核心 API 只有这么几个类：ObjectExtractor负责按页抽取文本对象，SpreadsheetExtractionAlgorithm是核心表格识别算法，BasicExtractionAlgorithm是简化版（适合无边框场景），Table是最终结果对象。日常使用根本不用关心算法细节，你只需要传一个PDFReader进去，告诉它“从第几页到第几页”，再指定一个提取模式就行。
选 Tabula 还有一个好处：它自带命令行工具和网页版tabula-java，方便你先用 GUI 环境验证 PDF 的表格结构能不能被识别，再回 Java 代码里跑批量任务，这个先验证后编码的习惯能省掉大量调试时间。
依赖坐标是这样的，Maven 直接加：
<dependency> <groupId>technology.tabula</groupId> <artifactId>tabula-java</artifactId> <version>1.0.5</version> </dependency> <dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>5.2.5</version> </dependency> <dependency> <groupId>com.opencsv</groupId> <artifactId>opencsv</artifactId> <version>5.9</version> </dependency>注意tabula-java 1.0.5默认依赖的PDFBox版本比较旧，如果你项目里其他组件用了新版本 PDFBox，可能出现NoSuchMethodError。解决办法是显式引入新版 PDFBox 覆盖，我项目里实际用pdfbox 2.0.30没出过问题。新旧版本差异并不是越大越好，PDFBox 2.x 的 API 比 1.x 稳，3.x 又把部分类挪了包路径，如果你的其他依赖绑死了 3.x，Tabula 可能直接起不来。
3. 核心原理与关键实现
3.1 表格识别原理：PDF 的坐标系和单元格推断
要理解 Tabula 为什么能“看懂”表格，得先理解它的执行逻辑。Tabula 的SpreadsheetExtractionAlgorithm干了两件事：第一，找到页面里的文本块（TextChunk）；第二，找页面里的表格线（Rule）。
文本块好理解，就是 PDF 内容流里每段文字的位置、大小、内容。表格线麻烦一点，PDF 有两种表示线的方式：一种是真正的矢量线（re或l操作符画的矩形和线条），另一种是用虚线或边框样式模拟的线。Tabula 只认前者，遇到后者就容易识别失败。它的容错机制是：如果检测到的垂直线不完整，允许“线缺失”合并同一行的单元格；但如果线差得太离谱，结果就碎了。
之后是单元格合并逻辑。Tabula 把每一列看成一个沿 X 轴的区间，每一行看成一个沿 Y 轴的区间。文本块落在哪个区间交叉点，就被划进哪个单元格。同一单元格里的多行文本（比如换行、列表），算法会根据线框的上下界把它们拼在一起。这也是为什么“无边框但是靠对齐”的表格，Tabula 默认模式下经常把它们合成一坨——因为算法没有线框作为行边界，两个相邻“逻辑行”就被并进同一个格子。
我画个简单流程便于理解：
- 从 PDF 页面提取所有文字块以及候选的垂直、水平线
- 根据线的交点生成候选单元格网格
- 把文字块按坐标映射到网格中
- 输出带行列属性的
Table对象
这个流程注定了 Tabula 的强项是“有线框的规则表格”，弱项是“无边框排版表格”。所以真遇到无边框表格，不要硬刚，要么教 Tabula 做人（指定extraction_method），要么后面用规则切割文本兜底。
3.2 核心代码：PDF 转 Excel 完整流程
我直接给大家一份可以跑的代码，注释都写在关键位置。
第一步，读取 PDF 文件并解析表格数据：
import technology.tabula.*; import technology.tabula.extractors.SpreadsheetExtractionAlgorithm; import technology.tabula.reader.CSVReader; import java.io.File; import java.io.IOException; import java.util.List; public class PdfTableExtractor { public static List<Table> extractTables(String pdfPath, int startPage, int endPage) throws IOException { // 加载 PDF 文件 try (PDFReader reader = new PDFReader(new File(pdfPath))) { // 抽取指定页码范围的对象，0 表示第一页 ObjectExtractor extractor = reader.getExtractor(); PageIterator pages = extractor.extract(startPage, endPage); // 表格识别算法 SpreadsheetExtractionAlgorithm algorithm = new SpreadsheetExtractionAlgorithm(); // 结果表集合 List<Table> tables = new java.util.ArrayList<>(); while (pages.hasNext()) { Page page = pages.next(); // 识别当前页的所有表格 List<Table> pageTables = algorithm.extract(page); tables.addAll(pageTables); } extractor.close(); return tables; } } }这段代码看着简单，但有几个容易忽略的细节。
ObjectExtractor的页码是从 0 开始数的，如果你 PDF 的目录写着“第 10 页”，代码里要用startPage = 9。endPage是包含关系的，想提取 1 到 3 页，得传extract(0, 2)。我把这个索引偏移写成常量PAGE_OFFSET = 1，每次传参先减一，免得后来团队成员看懵了。
第二步，把 Table 对象转成 Excel 文件。这里有两种写法：用 POI 的 XSSFWorkbook 生成.xlsx，以及用 OpenCSV 生成.csv。Excel 版更适合给业务人员看，因为能带格式；CSV 版更适合程序间对接，轻量通用。
import technology.tabula.Table; import technology.tabula.RectangularTextContainer; import org.apache.poi.ss.usermodel.*; import org.apache.poi.xssf.usermodel.XSSFWorkbook; import java.io.FileOutputStream; import java.util.List; public class ExcelWriter { public static void writeExcel(List<Table> tables, String outputPath) throws Exception { try (Workbook workbook = new XSSFWorkbook(); FileOutputStream fos = new FileOutputStream(outputPath)) { CreationHelper helper = workbook.getCreationHelper(); // 样式：表头加粗 CellStyle headerStyle = workbook.createCellStyle(); Font headerFont = workbook.createFont(); headerFont.setBold(true); headerStyle.setFont(headerFont); int sheetIndex = 1; for (Table table : tables) { Sheet sheet = workbook.createSheet("Table_" + sheetIndex++); // 遍历表格的行列 List<List<RectangularTextContainer>> rows = table.getRows(); for (int i = 0; i < rows.size(); i++) { Row excelRow = sheet.createRow(i); List<RectangularTextContainer> cells = rows.get(i); for (int j = 0; j < cells.size(); j++) { String cellText = cells.get(j).getText(); // 去掉 Tabula 可能带出的空白字符 cellText = cellText.replace("\u0000", "").trim(); Cell cell = excelRow.createCell(j); cell.setCellValue(cellText); if (i == 0) { cell.setCellStyle(headerStyle); } } } // 按内容自适应列宽（粗略版） for (int col = 0; col < table.getColCount(); col++) { sheet.autoSizeColumn(col); } } } } }这里有个性能提醒：autoSizeColumn是拿字体、单元格内容计算宽度的，数据量大时会非常慢。如果你一个 Excel 里要写十几张 Sheet，每张几千行，这个操作可能让程序卡几分钟。实际项目中，我只给表头列设置固定宽度，或者干脆跳过自适应，交给前端Excel 里的“自动调整列宽”按钮去处理，性能差距明显。
第三步，写 CSV 版本：
import technology.tabula.Table; import technology.tabula.RectangularTextContainer; import com.opencsv.CSVWriter; import java.io.FileWriter; import java.util.List; public class CsvWriter { public static void writeCsv(List<Table> tables, String outputPath) throws Exception { try (CSVWriter writer = new CSVWriter(new FileWriter(outputPath))) { for (Table table : tables) { List<List<RectangularTextContainer>> rows = table.getRows(); for (List<RectangularTextContainer> cells : rows) { String[] line = new String[cells.size()]; for (int i = 0; i < cells.size(); i++) { line[i] = cells.get(i).getText().replace("\u0000", "").trim(); } writer.writeNext(line); } // 表格之间加空行，便于人工区分多个表 writer.writeNext(new String[]{""}); } } } }CSV 是纯文本格式，天然跨平台，能用Excel、Numbers、Python的pandas直接读。但要注意 CSV 里如果单元格本身就包含逗号或换行符，OpenCSV 会自动加引号转义，这个机制是对的。千万别自己用String.join(",", cells)拼接，那样遇到含逗号的文本就废了。
3.3 不规则表格与合并单元格的血泪教训
上面这个方案处理“正规表格”没问题，但现实世界的 PDF 表格从来没这么听话。最常见的是三种问题。
合并单元格。PDF 里两个相邻单元格共用一个背景色或边框，导致 Tabula 把左右两个内容合并成一个单元格，或者把本来应该拆开的列并在一起。遇到这种情况，我一般先看合并的规律：如果合并总是发生在某些固定列，可以在后处理里手动按规则切分；如果规律不明显，只能导出后在 Excel 里手工调整了。没有银弹，这一点上 PDF 表格永远比不过 HTML 表格。
跨页表格。表格头一页，数据延伸到好几页，每页的行列结构都一样。Tabula 会为每页生成独立表格，所以你在汇总结果时，要自己把表头跳过，只保留数据行，然后顺序拼接。我封装了一个mergeAcrossPages方法，逻辑很简单：第一页取全部行，之后每页从第 1 行开始追加（默认 0 行为表头，索引从 1 开始取数据）。
无边框表格。这种最头疼，常见于政府公文、扫描版说明书。SpreadsheetExtractionAlgorithm会惨败。但 Tabula 还有个隐藏方法：用BasicExtractionAlgorithm替代。它不看表格线，只按文字“区块”聚类，结果虽然丑一点，但至少行没乱。如果你想进一步提升，可以把Page对象拿过来，手动设置verticalRulingLines和horizontalRulingLines，强行注入你自个算出来的边界线。这个方法网上资料很少，但确实能救活一部分无边框表格。
我举一个实操例子。某个表格其实没有竖线，只有横线，列边界全靠文本对齐区域推断。我先用 PDFBox 把每行文字的 X 坐标全部打出来，观察出第一列集中在 40-120 区间，第二列集中在 130-260，第三列在 270-400。然后手动在Page对象上加三条垂直线，再跑SpreadsheetExtractionAlgorithm，识别率直接提到 90% 以上。这种做法确实是靠人肉分析，但针对固定模板的文档，一次配置永久生效，值得投入。
3.4 乱码与中文编码处理
Java 读取 PDF 时，中文乱码是高频坑。先说结论：PDF 里的字体编码信息决定了你会不会乱码，跟你的代码关系不大。
旧版 PDF 常用Type1字体 + 自定义编码，字体内嵌的 CID 映射表一旦缺失，PDFBox 抽出来的中文就会变成乱码或方块。新版 PDF 多用TrueType字体子集，一般没问题。改善方法有三个：一是升级 PDFBox 到 2.0.30 以上，新版对字库解码的兼容性强很多；二是不要用PDFTextStripper.setSortByPosition(true)后再手动抠字符，直接让 Tabula 输出原文，避免二次拼接引入乱码；三是真的遇到字体缺失无法解，那就退到 OCR 路线，用 Tesseract 的 Java 封装（tess4j）配合中文语言包跑一遍。
OCR 路线别轻易上，因为速度慢、识别率受图像质量影响大。我给同事的优先级建议永远是：能抠文本流就别 OCR，能解析线框就别抠坐标。乱码问题也一样，先判断是不是 PDFBox 老版本导致的，不要一上来就换方案。
4. 常见问题与排查技巧实录
4.1 安装环境和依赖冲突
Tabula-Java 的 Maven 依赖其实会拖进一堆东西，最典型的是commons-logging和org.slf4j之间的冲突。如果你的项目是 Spring Boot，它自带logback，而 Tabula 内部用了commons-logging的接口，两边没对接好，启动时可能NoClassDefFoundError。处理办法是在依赖里统一用slf4j-api排除commons-logging：
<dependency> <groupId>technology.tabula</groupId> <artifactId>tabula-java</artifactId> <version>1.0.5</version> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency>另外一个坑是JDK 模块系统。如果你用 JDK 17+ 跑老代码，可能报java.lang.reflect.InaccessibleObjectException，因为 PDFBox 底层尝试反射访问java.awt的某些内部类。解决方案是加 JVM 启动参数：
--add-opens java.desktop/java.awt.font=ALL-UNNAMED如果是用 Maven 插件打包运行，记得在pom.xml里给maven-surefire-plugin配上argLine。
4.2 边距与旋转页导致识别偏移
PDF 不是所有页面都是“正”的。有些扫描版文档里，某一页倒了 90 度，或者页面左边距跟其他页不一样。Tabula 是按坐标网格算的，页面一旦旋转，所有文本块的 X/Y 坐标全都会变，识别结果直接错位。
排查方式很简单：用PDFRenderer把页面渲染成图片，Ctrl+拖拽看一眼就知道是不是歪的。代码层面可以用 PDFBox 的PDRectangle读页面属性里的/Rotate字段：
PDDocument doc = PDDocument.load(new File(pdfPath)); int rotation = doc.getPage(0).getRotation();发现旋转页后，有两种处理：一是用 PDF 编辑器把页面转正后另存，再去解析；二是在 Tabula 提取前，用 PDFBox 的AffineTransform自己旋转坐标再做提取。实操中我建议选第一个，简单省事还不会引入坐标换算误差。
4.3 导出 Excel 后数字变科学计数法
这是一个特别隐蔽的坑。Tabula 输出的单元格文本"1234567890123"，直接塞进 Excel 后，Excel 会自动把它当成超长数字，显示成1.23457E+12，看着没问题，一打印就露馅。
解决方式很简单，在 POI 写入时把单元格设置成文本格式：
CellStyle textStyle = workbook.createCellStyle(); DataFormat fmt = workbook.createDataFormat(); textStyle.setDataFormat(fmt.getFormat("@")); // @ 表示文本 cell.setCellStyle(textStyle);但如果你成批导出大量数据，这种方案速度会慢。另一个思路是导出到 CSV，然后用 Excel 导入向导设置列类型为“文本”。CSV 没有这种自动格式化的烦恼，因为它就是纯文本。两相权衡，你要数据可再加工，用 CSV；要交付给不懂技术的业务同事，用 Excel 而且必须提前设文本格式。
4.4 多线程批量处理 PDF 的性能优化
批量解析几千个 PDF 是常态。如果文件之间没有依赖关系，直接用线程池并行处理。我这边实践过的优化方案是：
- 用
ExecutorService固定线程数，比如 8 线程，每个线程处理一个 PDF 的全部分页 - 输出到一个
ConcurrentLinkedQueue，主线程负责批量写 Excel/CSV，避免多线程同时写同一个文件 - 解析时按页流式处理，不要一次性
load整个 500MB 的 PDF 到内存，PDFReader按Page消费完就释放 - 设置超时保护：单页解析超过 10 秒就跳过并记录日志，防止某个损坏 PDF 把任务卡死
实测下来，1000 个平均 20 页的 PDF，单线程要跑半小时，8 线程大概 5 分钟出头。主要瓶颈不在 CPU，而是磁盘 IO 和内存回收。如果你的 PDF 是放在对象存储里，强烈建议先下载到本地临时目录再解析，直接走网络流会让PDFReader反复 seek，性能极其糟糕。
4.5 常见问题速查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 表格内容合并成一整个单元格 | 无边框表格，或虚线框不被识别 | 用BasicExtractionAlgorithm或手动注入表格线 |
| 导出 Excel 中文变方块 | 字体缺失 / PDFBox 版本过旧 | 升级 PDFBox 2.0.30+，必要时换 OCR |
| 页码错位，解析到非目标页 | ObjectExtractor页码从 0 开始 | 统一封装startPage - 1逻辑 |
| 内存溢出 | 一次性加载超大 PDF | 使用PageIterator流式处理，控制并发放数 |
| 数字变科学计数法 | Excel 默认数字格式 | POI 设置文本格式，或改用 CSV |
| PDF 某页旋转导致全表乱掉 | 页面含旋转属性 | 预处理页面 / 旋转成 0 度再解析 |
| 解析结果列错位 | 同一 PDF 不同页边距不一致 | 检查页面尺寸，必要时按页单独配置提取区域 |
5. 全场景实战：从单文件到批量管线的完整落地
5.1 场景 A：单个 PDF 文件转 Excel
这个场景最简单，适合新手上手验证。我把完整流程串一遍：先初始化一个PdfExtractService，传入 PDF 路径和输出路径，调用extractTables拿到表格集合，再调用writeExcel落盘。
完整代码骨架：
public class PdfToExcelDemo { public static void main(String[] args) throws Exception { String pdfFile = "/data/input/report_2026.pdf"; String excelOut = "/data/output/report_2026.xlsx"; // 1. 提取表格 List<Table> tables = PdfTableExtractor.extractTables(pdfFile, 1, 3); // 2. 打印第一张表格的行列结构（调试用） if (!tables.isEmpty()) { Table first = tables.get(0); System.out.println("行数: " + first.getRowCount() + ", 列数: " + first.getColCount()); System.out.println("首行首列内容: " + first.getRows().get(0).get(0).getText()); } // 3. 写入 Excel ExcelWriter.writeExcel(tables, excelOut); System.out.println("写入完成: " + excelOut); } }这里有个细节：Table.getRows()返回的是List<List<RectangularTextContainer>>，每一格内容是RectangularTextContainer对象。很多新手直接toString()，结果打印出的是坐标信息，不是文本。一定要调用.getText()。这也是 Tabula 官方文档里最容易忽略的地方。
5.2 场景 B：多文件批量处理与断点续传
如果文件数量多了，就要考虑“跑挂了从哪接着来”。我的做法是维护一个处理进度表（数据库表或本地 JSON），记录每个文件的处理状态：待处理、处理中、成功、失败。程序启动时先查待处理列表，处理成功后回写状态。这样即使中途崩溃，重启后也能自动跳过已完成的文件。
核心伪代码逻辑：
List<PdfTask> tasks = taskRepo.findByStatus(PdfStatus.PENDING); ExecutorService pool = Executors.newFixedThreadPool(8); for (PdfTask task : tasks) { pool.submit(() -> { task.setStatus(PdfStatus.PROCESSING); try { List<Table> tables = PdfTableExtractor.extractTables( task.getFilePath(), 1, task.getEndPage()); ExcelWriter.writeExcel(tables, task.getOutputPath()); task.setStatus(PdfStatus.SUCCESS); } catch (Exception e) { task.setStatus(PdfStatus.FAILED); task.setErrorMsg(e.getMessage()); } taskRepo.save(task); }); } pool.shutdown();这里要特别提醒：不要在循环里直接建线程，一定要用线程池，否则文件一多，线程数两三千，系统直接崩。
失败重试也是个重点。我通常对每个文件做三次重试，第二次和第三次之间加 1 秒延迟。有些 PDF 解析失败是偶发性的 IO 抖动或临时文件句柄被占用，重试效果不错。要是三次全失败，就把错误信息记下来，连同文件名、失败页码一起告警，方便人工抽出来排查。
5.3 场景 C：定时任务与增量更新
PDF 来源可能是 FTP、邮件附件或网盘同步目录。你可以用 Spring 的@Scheduled注解写一个定时扫描任务，对每个新出现的 PDF 文件做增量解析：
@Component public class PdfSyncScheduler { @Scheduled(cron = "0 0/30 * * * ?") public void scanAndProcess() { File dir = new File("/data/inbox"); File[] pdfs = dir.listFiles((d, name) -> name.endsWith(".pdf")); if (pdfs == null) return; for (File pdf : pdfs) { // 检查是否已经处理过，用文件名 hash 作为唯一键 if (processedRepo.existsByFileHash(hashFile(pdf))) { continue; } processPdfFile(pdf); processedRepo.save(new ProcessedRecord(hashFile(pdf))); } } }增量设计的核心是“幂等”。不管任务跑了多少次，同一个文件只产出一次解析结果，不会有重复数据。文件 hash 用 MD5 就够了，在目录规模不大时，选 MD5 比 SHA256 快不少。担心碰撞就升级成 SHA-256，对单机脚本来说差别不大。
5.4 下一步扩展：怎么把提取结果接入你的业务系统
表格提取出来只是第一步，后续才是大头。通常有三种走向：
入库分析：把提取出的行数据灌进 MySQL、PostgreSQL，或者直接写到 ClickHouse 做 OLAP。这个阶段要处理字段映射——PDF 里的“姓名”“联系电话”到数据库里的name、phone，映射关系可以提前配置成模板，新建不同类型的任务时直接套模板。
流程自动化：提取完以后把结果作为附件发邮件、写入钉钉/企微群机器人、或者触发审批流。比如财务对账 PDF 解析完成后，直接把异常差异行抽出来发给财务人员，免去人工下载再对比的过程。
数据清洗：PDF 里的表格多多少少都有脏数据，比如金额列混入“-”、百分比带空格、日期格式不统一。清洗规则的优先级是：先做类型统一（数字、日期、文本），再做去重（同一行出现多次但某列不同），最后做字段级校验（邮箱、手机号、金额范围）。
如果后面要接 AI 或 BI 看板，建议最终落地成 Parquet 格式再对接，但那是另一个话题了。对绝大多数团队来说，Excel/CSV 足够满足业务需求，先把这步跑通再考虑更重的下游。
6. 最后再分享一点我的体会
做了这么多 PDF 解析项目，我最深的感受是：没有万能的工具，只有适合场景的方案。TCPDF、FPDF 生成的规范表格，Tabula 基本能一把梭；老系统导出的畸形 PDF，就得靠人工补线框、搞规则切割，甚至在关键业务上直接用 Python 的 pdfplumber 做验证对比。做技术选型时，花半小时做 POC（概念验证）远远好过看三天文档然后拍脑袋定方案——这是我在多个项目中反复印证过的做法。
还有一个小技巧分享给大家：开发阶段准备一批不同类型的测试 PDF，有线框表格、无边框表格、跨页表格、旋转页、带水印页、纯扫描件，六种类型各 5 个。每次改完代码，先把这 30 个文件跑一遍，用输出结果做一个“对照基线”，这样不会出现“上次那个模块能跑，这次改了另一个地方结果全乱”的情况。我管这个叫“PDF 回归测试集”，它帮我挡住过至少三次明显的识别回退。
如果你遇到一个特别偏门的 PDF，解析不出来，先别急着怪代码。用 Tabula 的网页版拖进去看一眼，它能识别多少，你的代码就能识别多少——网页版和 Java 库是同一个内核。如果网页版也是白搭，那基本可以断定这个 PDF 不是常规的结构化文档，需要走 OCR 或者人工预处理，而不是在提取代码上疯狂堆时间。
PDF 表格提取这条路，初看是工具调参，实际做久了你会发现，真正吃经验的是对文档结构的判断和对异常数据的容忍设计。希望这篇文章能帮你省下我当年踩坑的时间。
