做Java开发的朋友十有八九都遇到过这种需求客户发来一份PDF对账单要你把这些数据整理成Excel财务那边拿到一批PDF合同想把关键字段落到表里做汇总运营手里攒了一堆PDF格式的报表需要转成结构化数据再进数仓。这类“PDF转Excel”的需求在业务系统里出现频率极高但真正动手做的时候很多人会发现它并不是想象中“读出来、写进去”那么简单。这篇文章把我自己的实测经验整理出来从最基础的“把PDF文本逐行写入Excel”到进阶的“按坐标重建表格结构”再到中文乱码、表格错位、扫描件识别这些让人头疼的问题处理都会一步步说清楚。适合正在写文档处理工具、或者准备做数据抽取入库的Java工程师参考代码和思路都能直接落地。1. 工具选型与方案对比1.1 先搞清楚PDF转Excel的真实难点先说结论PDF转Excel之所以麻烦根源在于PDF本身没有“表格”这个概念。PDF是一种版式文档格式它底层记录的是“某个字符在页面上的坐标、字体、字号、颜色”而不是“第几行第几列、单元格跨几行几列”。你在PDF里看到一个规规整整的表格在解析器眼里不过是一堆带坐标的字符碎片。Excel则完全是另一种模型它天然就是由行、列、单元格组成的二维表格。这两种格式之间的差异决定了转换的本质不是在“搬运数据”而是在“重建结构”。你需要把PDF里分散的字符通过它们的坐标位置、字体大小、间距规律重新推断出哪些字符属于同一行、哪些字符属于同一列、哪里存在合并单元格。这个推断过程就是整个转换工具的算法核心也是最容易出现BUG的地方。理解了这一点你再看市面上的各种转换方案思路就会清晰很多有的方案擅长提取文本本身有的方案擅长识别表格边界有的方案干脆把整个页面当成图片输出到一个Excel单元格里。不同的方案面向不同的问题层次选错工具后面所有工作都会事倍功半。1.2 Java生态主流方案盘点Java生态里能处理PDF的库不少但适合做“PDF转Excel”的其实就那么几个我列一个对比表方便你按需选择方案开源协议表格识别能力开发成本典型场景Apache PDFBoxApache 2.0免费无现成表格识别需要自研坐标算法高但灵活可控需要深度定制转换逻辑、文本与坐标都可用的场景TabulaMIT免费专攻表格抽取能识别基本行列结构中API简单规整表格、数据抽取不追求复杂版式保真iTextAGPL商用需授权功能全面但表格提取不是其核心定位中高生成PDF、数字签名、表单处理为主转换是附加能力Spire.PDF商用授权免费版有页数与水印限制转换效果较好API封装度高低开箱即用项目预算允许、追求快速交付的场景pdf2jsonMIT输出JSON格式的文本与位置信息中需要把PDF数据接入其他系统的场景这里要特别说明一下Apache PDFBox是整个方案里最核心的开源库。它的强大之处在于不仅能提取纯文本还能通过PDFTextStripper的子类拿到每个字符的坐标这就为自研表格识别算法提供了基础材料。很多商业软件内部做的表格识别本质上也是在PDFBox这类库提供的底层数据之上加了自己的算法模型。Tabula是专门做表格抽取的它内部也依赖PDFBox但把表格识别逻辑封装好了。对于页面规整、表格线清晰的PDFTabula开箱即用的效果确实不错。但它的算法偏“启发式”面对复杂嵌套表、跨页表、无边框表时识别率会明显下降而且你很难干预它的内部判断逻辑。iText和Spire.PDF我也简单提一下。iText在Java PDF领域非常有名但它主要擅长的是创建和操作PDF文档做内容提取和结构识别并非它的强项。Spire.PDF的转换API做得很友好几行代码就能把PDF转成Excel但免费版有页数限制商用还要评估授权费用适合预算充足、不想在算法上投入太多时间的团队。1.3 选型建议与推荐组合我个人在做这类项目时的选型逻辑一般分三步走第一步先确认PDF是文本型还是扫描型。文本型PDF里面有真实的字符数据PDFBox能提出来扫描型PDF本质是图片任何库都提不出文本必须走OCR路线。这一步直接决定方案走向。第二步评估表格复杂度。打开几页真实样本看两眼如果表格是横平竖直、每列都有清晰边界行列不多那用Tabula或者自研坐标算法都行。如果表格里有复杂的合并单元格、斜线表头、嵌套结构商业库可能更省事但也不是万能的很多时候还是得靠自研逻辑二次处理。第三步考虑团队后续维护的意愿。自研方案前期投入大但算法逻辑完全掌握在自己手里遇到奇葩PDF可以随时调整阈值和规则。用现成库前期省事但遇到边界情况往往只能干瞪眼要么等库更新要么被迫加一层后处理。我的推荐组合是“PDFBox POI”。PDFBox负责从PDF里拿到文本和坐标POI负责生成Excel文件。这套组合完全开源免费、社区活跃、可控性强虽然表格重建算法要自己写但对于一个长期要做文档处理的系统来说这笔投入是值得的。后面文章里的所有代码都基于这个组合展开。2. 基础转换实战把PDF文本导入Excel2.1 搭建Maven项目与依赖配置先建一个普通的Maven项目在pom.xml里引入两个核心依赖PDFBox负责读PDFPOI负责写Excel。dependency groupIdorg.apache.pdfbox/groupId artifactIdpdfbox/artifactId version2.0.31/version /dependency dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version5.2.5/version /dependency版本上我用的是PDFBox 2.0.x这个版本在生产和社区中使用最广、资料最多API也足够稳定。POI选5.x是因为它修复了旧版本很多Excel读写上的兼容问题而且对.xlsx格式的支持更完善。有一点要提醒你POI的依赖树里有不少传递依赖比如commons-io、log4j-api这些如果你的项目里已经引入了其他版本的相同库记得检查一下冲突。我遇到过不少次因为log4j版本不一致导致运行时报NoSuchMethodError的情况排查起来非常浪费时间建议一开始就用Maven的依赖树检查工具看清楚。2.2 用PDFBox提取文本内容PDFBox里提取文本最简单的方式就是使用PDFTextStripper类。它会把PDF每页的文本内容按阅读顺序拼接成一个大字符串实现入下import org.apache.pdfbox.pdmodel.PDDocument; import org.apache.pdfbox.text.PDFTextStripper; import java.io.File; public class PdfTextExtractor { public static void main(String[] args) throws Exception { try (PDDocument document PDDocument.load(new File(input.pdf))) { PDFTextStripper stripper new PDFTextStripper(); String content stripper.getText(document); System.out.println(content); } } }这段代码能跑通但你要理解它背后的行为。PDFTextStripper输出文本时基本遵循“从左到右、从上到下”的阅读顺序换行位置则由字符的垂直坐标决定。这种输出对纯段落文本很友好但对表格来说它只会把单元格里的内容按顺序排下来完全丢掉了“哪几个字符属于同一列”的信息。所以基础方案适合的场景很有限PDF内容是纯段落、报告、合同条款不包含复杂的行列结构。一旦遇到真正的表格用这个方案读出来的内容就是一锅粥。2.3 用POI生成Excel文件文本提取出来之后下一步就是把文本写入Excel。这里我用POI的XSSFWorkbook来生成.xlsx格式文件。import org.apache.pdfbox.pdmodel.PDDocument; import org.apache.pdfbox.text.PDFTextStripper; import org.apache.poi.xssf.usermodel.XSSFWorkbook; import org.apache.poi.ss.usermodel.Row; import org.apache.poi.ss.usermodel.Sheet; import java.io.File; import java.io.FileOutputStream; public class PdfToExcelBasic { public static void main(String[] args) throws Exception { try (PDDocument document PDDocument.load(new File(input.pdf))) { PDFTextStripper stripper new PDFTextStripper(); String content stripper.getText(document); String[] lines content.split(\\r?\\n); try (XSSFWorkbook workbook new XSSFWorkbook()) { Sheet sheet workbook.createSheet(Sheet1); for (int i 0; i lines.length; i) { Row row sheet.createRow(i); row.createCell(0).setCellValue(lines[i]); } try (FileOutputStream out new FileOutputStream(output.xlsx)) { workbook.write(out); } } } } }这里有个细节值得注意我先用split按换行把文本切成数组然后逐行写入Excel的第一列。这个“先切分、再写入”的步骤看起来平淡无奇但它决定了你要把PDF的哪个内容放到Excel的哪个位置。如果你需要按段落、按页分区输出应该在写入前就组织好数据结构而不是在写入过程中临时判断。代码里我用了XSSFWorkbook对应的是.xlsx格式支持最大1048576行、16384列体积大但兼容性好。如果你需要生成.xls格式可以换HSSFWorkbook但.xls的行列上限小得多现在业务系统里基本都推荐.xlsx没必要用老格式给自己挖坑。2.4 基础方案的适用边界把这段代码跑通之后你大概就能感受到“基础转换”的局限了。它把所有文本塞进了Excel的第一列每行一个单元格且列宽、行高、字体、边框全部是默认值美观和实用性都谈不上。真正的问题在于一旦PDF里有一个三列十行的表格这段代码就会把它的内容按阅读顺序全部输出到第一列左边一列的文字、中间一列的文字、右边一列的文字顺序堆在一起原来的表格结构完全丢失。想要让“第一列的数据在A列、第二列的数据在B列”就必须拿到每个字符的坐标再按坐标重建行列关系。这就进入了高级设置的范畴。所以我的建议是如果你只是临时想把几页PDF的文字内容导出来人工处理上面这段基础代码够用了。但如果你想做一个能应对真实业务数据的转换工具至少需要继续往下看高级方案同时在代码里保留很多参数和调试开关因为你接下来的大部分时间都会花在调整算法阈值上。3. 高级设置按坐标重建表格结构3.1 获取每个字符的坐标要重建表格第一步是拿到每个字符在PDF页面上的坐标。PDFBox提供了很基础但很有用的钩子你可以继承PDFTextStripper重写writeString方法这样每次输出一段文本时都能同时拿到对应的TextPosition列表。TextPosition是PDFBox里的一个关键类它记录了单个字符的坐标、字体、字号等信息。其中getXDirAdj()返回字符的逻辑x坐标getYDirAdj()返回逻辑y坐标getUnicode()返回字符本身。逻辑坐标和物理坐标的区别在旋转页面、有裁剪区域时会体现出来普通场景下可以近似理解为页面上从左到右、从上到下的像素坐标。下面是提取坐标的自定义类import org.apache.pdfbox.text.PDFTextStripper; import org.apache.pdfbox.text.TextPosition; import java.io.IOException; import java.util.ArrayList; import java.util.List; public class CoordinateTextStripper extends PDFTextStripper { private final ListTextPosition positions new ArrayList(); public CoordinateTextStripper() throws IOException { super(); } Override protected void writeString(String text, ListTextPosition textPositions) throws IOException { positions.addAll(textPositions); super.writeString(text, textPositions); } public ListTextPosition getPositions() { return positions; } }使用方式也很直接try (PDDocument document PDDocument.load(new File(input.pdf))) { CoordinateTextStripper stripper new CoordinateTextStripper(); stripper.getText(document); ListTextPosition positions stripper.getPositions(); for (TextPosition pos : positions) { System.out.printf(字符%s x%.2f y%.2f%n, pos.getUnicode(), pos.getXDirAdj(), pos.getYDirAdj()); } }跑出来的结果是大量带坐标的字符看起来像点云数据。这个阶段你会强烈感受到PDF“没有表格结构”这句话的含义——你看到的就是一堆坐标点需要自己把它们组织成行和列。3.2 行与列的聚类算法拿到坐标点之后最核心的算法就是“聚类”。我先处理行把y坐标相近的字符归到同一行里。因为PDF里同一行文字虽然y坐标不完全一致但一定在很小的范围内波动比如同一行里字母的基线大体相同偶尔有上标、下标但波动也不会太大。聚类逻辑是先按y坐标从小到大排序配合x坐标做二次排序再遍历所有字符如果当前字符的y坐标和上一行基准y坐标的差值小于某个阈值就认为它属于同一行否则开启新行。阈值一般设置在2到3个像素左右你可以根据实际PDF的分辨率调整。import org.apache.pdfbox.text.TextPosition; import java.util.ArrayList; import java.util.Comparator; import java.util.List; public class TableStructureBuilder { private static final double ROW_TOLERANCE 2.5; public static ListListTextPosition groupByRow(ListTextPosition positions) { ListTextPosition sorted new ArrayList(positions); sorted.sort(Comparator.comparingDouble(TextPosition::getYDirAdj) .thenComparingDouble(TextPosition::getXDirAdj)); ListListTextPosition rows new ArrayList(); double lastY Double.NaN; ListTextPosition currentRow null; for (TextPosition pos : sorted) { if (currentRow null || Math.abs(pos.getYDirAdj() - lastY) ROW_TOLERANCE) { currentRow new ArrayList(); rows.add(currentRow); } currentRow.add(pos); lastY pos.getYDirAdj(); } return rows; } }行聚类做完之后再对每一行做列聚类。列聚类的思路完全相同只不过把y坐标换成x坐标。注意列聚类时要警惕两种情况一是同一单元格里的字符之间有额外空格导致被错误分成两列二是两个实际不同的列恰好因为列距过近被错误合并成一列。处理办法是同时参考x坐标差值和字符间距一般超过一个字符宽度的x间隙就可以判定为列边界。更稳妥的办法是统计该行所有字符的x坐标分布找出明显的“间隙”作为分列点。public static ListListTextPosition groupByColumn(ListTextPosition row, double tolerance) { ListTextPosition sorted new ArrayList(row); sorted.sort(Comparator.comparingDouble(TextPosition::getXDirAdj)); ListListTextPosition columns new ArrayList(); double lastX Double.NaN; ListTextPosition currentColumn null; for (TextPosition pos : sorted) { if (currentColumn null || Math.abs(pos.getXDirAdj() - lastX) tolerance) { currentColumn new ArrayList(); columns.add(currentColumn); } currentColumn.add(pos); lastX pos.getXDirAdj(); } return columns; }这两个方法组合起来就能把“点云字符”还原成“二维字符矩阵”。再用StringBuilder把每个单元格里的字符拼起来传入Excel的对应行列即可。这里的核心体会是写算法不如调参数花时间多每个PDF的字体、字号、间距都可能不同固定阈值不可能通吃所以我会把阈值定义成可配置的参数后续对接新数据源时不用改代码。3.3 写入Excel并保留合并单元格表格结构重建好后写入Excel就顺手多了。这一步依然用POI但相比基础版要多做几件事设置列宽、加边框、处理合并单元格。先写一个简单的样式工具方法import org.apache.poi.ss.usermodel.*; import org.apache.poi.xssf.usermodel.XSSFWorkbook; public class ExcelStyleHelper { public static CellStyle createCellStyle(XSSFWorkbook workbook) { CellStyle style workbook.createCellStyle(); style.setBorderTop(BorderStyle.THIN); style.setBorderBottom(BorderStyle.THIN); style.setBorderLeft(BorderStyle.THIN); style.setBorderRight(BorderStyle.THIN); style.setAlignment(HorizontalAlignment.CENTER); style.setVerticalAlignment(VerticalAlignment.CENTER); Font font workbook.createFont(); font.setFontName(微软雅黑); font.setFontHeightInPoints((short) 11); style.setFont(font); return style; } }合并单元格的需求很常见。重建矩阵时如果某一行里连续几个单元格内容为空而它们上方的单元格是一个跨越多列的内容就可以推断这是一个横向合并单元格。把合并区域用POI的CellRangeAddress注册到Sheet上import org.apache.poi.ss.util.CellRangeAddress; import org.apache.poi.xssf.usermodel.XSSFSheet; sheet.addMergedRegion(new CellRangeAddress(firstRow, lastRow, firstCol, lastCol));纵向合并的推断逻辑类似同一列里连续几行的单元格为空且左侧或右侧相邻列对应位置有内容。当然这种“空值推断法”只能处理相对规整的合并场景碰到更复杂的嵌套合并需要引入更完整的规则甚至人工标记。这里我提醒一句合并单元格是转录过程中最容易出错的环节。算法推断出来的合并区域一定要在输出后人工抽查几条数据对比原PDF。合并判断错误导致的数据错位比单纯的乱码更难发现。3.4 复杂表格的处理思路前面讲的行列聚类算法对于“边框完整、行列规整、无合并”的表格基本够用。但真实业务里的表格特别是从业务系统导出的PDF往往没有这么友好。常见的坑包括一是表头跨多页。第一页有完整表头第二页起可能只显示列名缩写或者干脆不显示。转换时要注意每个页面的首行表格结构可能不同不能假设整份PDF的列数一致。二是表格里嵌套了图示、签名区域、盖章图片。这些对象不是文本字符坐标聚类算法不会处理它们但它们的空白区域会占据大量空间导致行列判断时出现断裂。处理思路是把页面按坐标划分多个区块先识别“文本密集区”和“空白区”再在密集区内做行列聚类。三是同一单元格里的文本自动换行。一个长文本单元格在PDF里会显示成三行这三行在y坐标上各不相同。如果不处理算法会把一个单元格拆成三个逻辑行。解决思路是当一个单元格的内容跨越多行时垂直方向上相邻的多个“逻辑行”如果x坐标范围完全一致且中间没有其他列的文本穿插就应合并为一个单元格。这些复杂情况没有银弹只能针对性地增加规则。我的经验是复杂的PDF转换项目最后一定是“算法规则人工干预”三管齐下。算法负责80%的规整内容规则负责处理那些常见变体剩下实在识别不了的输出标记让运营人员单独处理。别追求百分之百自动化那是给自己找不痛快。4. 常见问题与排查技巧实录4.1 中文乱码到底出在哪个环节中文乱码是做PDF文本提取时遇到最多的问题但有意思的是大多数中文乱码根本不出在PDFBox身上。第一步要做的是验证“PDFBox提出来的文本本身是否正常”。直接把CoordinateTextStripper提取出来的文本或者坐标字符打印到控制台如果控制台显示的中文完全正常那PDFBox没问题问题出在Excel渲染环节——很可能是Excel单元格的字体没有设置为中文字体导致部分中文显示为乱码或方框。解决办法就是前面代码里给单元格设置“微软雅黑”或“宋体”这类中文字体。如果控制台打印出来的文本本身就是乱码那就要查PDF本身了。PDF里的文本编码有两种来源一种是直接以Unicode存储PDFBox提取无压力另一种是用自定义CMap映射的字体编码尤其是某些国产软件生成的PDF里面嵌入的字体子集没有完整的Unicode映射表PDFBox提取时会得到错误的Unicode字符。这种情况没什么通用的解决办法往往需要做字体映射的逆向匹配工作量很大。我的建议是先确认这类PDF的占比如果只是少数历史文件转人工处理或者用截图转OCR都比死磕字体映射划算。还有一种乱码容易被忽视——PDFBox版本问题。老版本的PDFBox在处理某些新版PDF标准特性时字符映射会出现偏差。升级到新版本常常能解决一批莫名其妙的问题这也是我推荐大家用近两年维护的版本的原因。4.2 扫描版PDF与OCR场景如果PDF是扫描件直接放弃PDFBox提取文本这条路因为它输出来的只会是空白。扫描版PDF的每一页都是图片没有任何真实字符数据。要把它转成Excel必须先走OCR识别。Java生态里常用的方案是Tesseract通过tess4j这个JNI封装库调用。OCR本身能识别出文字和大致位置但表格结构识别依然得靠自己处理。Tesseract输出的结果通常按块返回文字和矩形坐标把这些坐标拿过来再套用前面讲的行列聚类算法理论上还是能重建表格的。但说实话扫描件转Excel的效果受扫描质量、倾斜角度、表格线清晰度影响极大。倾斜的扫描页会导致同一行文字的y坐标波动剧烈必须先做图像矫正。表格线破损会导致行列边界判断混乱需要形态学处理补线。这些工作已经属于图像处理范畴和PDF解析关系不大了。我的建议是如果业务的扫描件比例不高与其投入大量时间做OCR不如给运营配一个半自动工具——OCR识别出文本人工在界面上框定表格区域再自动生成Excel。这对业务实用性和开发成本来说往往是更优解。4.3 表格错位和串行的排查顺序表格错位是坐标聚类算法最常见的故障表现。症状是某些单元格的内容跑到了错误的列或者某些行被一个字符的错误坐标拆成了两行。我建议按下面的顺序排查顺序很重要第一步先输出页面所有字符坐标人工观察几行数据的x、y分布是否合理。如果某个字符的y坐标明显偏离同一行的其他字符很可能它在PDF里是上标、下标或者基线位移导致的。第二步检查行聚类阈值。阈值太小同一行会因为1像素的波动被拆成多行阈值太大两行文字会因为行距过窄被合并。根据PDF的字号大小行距一般在字号的1.2到1.5倍之间你可以统计一下相邻行y坐标差值的中位数再来设阈值。第三步检查列聚类时的空格问题。有些单元格内容里有大量连续空格如果你的算法在遇到x坐标间隙时直接切分很容易把一个单元格切成多个。需要加上“超过多少像素的间隙才切分”这个约束条件。第四步检查页眉页脚和页码是否混进了表格数据。页眉页脚的文字通常出现在页面顶部和底部的固定区域它们的y坐标往往和表格正文有一定距离但如果表格刚好延伸到页面底部附近页码容易被误识别为表格行。处理办法是直接读取页面尺寸过滤掉顶部和底部固定像素范围内的字符。4.4 问题速查表下面这个速查表是我项目里的内部文档精简版遇到问题可以对照着看问题可能原因建议处理方式中文乱码但控制台正常Excel单元格字体不支持中文设置单元格字体为微软雅黑或宋体中文乱码且控制台乱码PDF字体子集无Unicode映射检查PDF生成工具必要时走OCR或人工提取结果为空扫描版PDF无文本层改用OCR方案同一行被拆成多行y聚类阈值过小统计行距中位数后调大阈值两行被错误合并y聚类阈值过大调小阈值或按字号动态计算一列被拆成多列x坐标间隙切分过于敏感增加最小间隙像素约束页码混入表格数据底部固定区域文本未过滤按页面尺寸过滤页眉页脚区域合并单元格丢失空值推断逻辑不完善结合坐标范围判断或人工标记大文件转换内存溢出PDDocument加载整个文件使用PDFBox的分页解析或提高堆内存这张表格看起来很简单但每一条背后都是我调了好几天才总结出来的经验。遇到问题时别急着改代码先判断故障属于哪个层次——是文本提取层、坐标分析层还是Excel输出层。层次判断对了问题基本上就解决了一半。5. 实操心得与进一步建议5.1 不要忽略页眉页脚和页码这是我实际项目里踩过很深的一个坑。有一批客户发来的PDF报价单每页顶部都有一个带Logo的页眉区底部是页码和公司抬头。如果直接跑坐标聚类页眉里的“XX公司报价单”会被当成表格的第一行而且因为它在页面顶部y坐标最小排序后还会出现在Excel的第一行。更麻烦的是页眉的x坐标范围覆盖整个页面宽度它会把表格的前几列全部“吸收”到同一行里造成大规模错位。解决思路很直接在聚类之前根据页面的MediaBox拿到页面宽度和高度然后屏蔽顶部和底部各几十像素范围内的字符。具体屏蔽多少取决于你的PDF页边距大小我一般用总高度的5%作为过滤区间再根据实际输出微调。这个过滤操作放在CoordinateTextStripper的writeString方法里做只把符合条件的TextPosition加入列表后续算法完全不用感知这部分逻辑。处理页眉页脚时还有一点要注意要按页过滤不要全局过滤。因为有些PDF只有第一页有完整页眉后面几页页眉内容略有不同甚至某些页根本没有页眉。按页处理能避免一竿子打死保留有效页面里的数据。5.2 批量转换时的工程化注意事项如果你要把这个转换工具嵌入到业务流程里面对的是成百上千份PDF那单线程逐份转换肯定不行。我的建议是引入线程池做并发但要注意几个关键点。PDDocument不是线程安全的每个线程必须独立加载自己的PDF文件绝对不能多个线程共用同一个PDDocument实例。文件路径列表可以先提前扫描好再提交给线程池处理。每个线程内部完成“加载PDF→提取坐标→重建表格→写入Excel→关闭所有资源”的完整生命周期。资源的关闭顺序也很重要。先关Excel文件的FileOutputStream再关workbook最后关PDDocument。虽然POI和PDFBox都实现了Closeable但如果你在写入过程中抛异常try-with-resources能保证关闭但Excel文件可能会残留半成品。我的做法是先用一个临时文件写入写入完整后再rename到最终路径这样至少保证不会覆盖掉上一次的完整结果。内存方面如果单个PDF页数很多PDFBox会把整个文档结构加载进内存。2.0版本里PDF有分页加载机制可以只对需要的页做解析但代价是每次setStartPage/setEndPage都要重新加载资源。对于大部分业务场景更好的办法是给JVM堆内存设大一些同时注意POI生成Excel时也会占用内存两者叠加要预留足够余量。我曾经在默认堆内存256M的服务器上跑转换一次处理几十页PDF直接OOM后来把堆内存调到2G才稳定下来。另外建议做一个回退机制。转换结果先不直接覆盖正式数据表而是输出到“待确认”区域由业务人员在快速预览工具里核对一批结果后再一键导入正式库。这个流程上的设计虽然和代码无关但对于文档转换这类错误率很难降到零的场景来说是保证系统可靠性的重要一环。最后再分享一点个人经验。PDF转Excel这个功能听起来简单真正耗时的从来不是写第一版代码而是处理真实数据里的各种意外。我自己的习惯是拿到新一批PDF时先挑三五页最具代表性的样本完整跑一遍转换把输出Excel和原PDF逐格对齐检查确认无误之后再上全量任务。这步人工抽检看起来“土”但正是它帮我规避了无数次“批量转换后数据全错”的夜间事故。转换工具拼的从来不只是一行行代码而是对业务数据的理解和尊重。