SAX解析Excel：startRow、cell、endRow回调机制与内存优化实战

做Excel解析的同行，十有八九都被大文件卡死过内存。上次我处理一个50MB出头的xlsx，用DOM方式直接OOM，换成SAX事件解析后，全程内存占用稳在120MB以内，速度还快了一个量级。今天就把这块的核心逻辑彻底聊透：SAX模式下startRow、cell、endRow这几个回调到底按什么顺序触发，应该在哪一步做数据落地，怎么避开常见的坑。

先说清楚一个概念：SAX解析Excel（尤其是xlsx格式）之所以省内存，是因为它把Excel文件当成一个ZIP压缩包里的XML流，按节点逐个读取、逐个触发事件，整个过程不需要把整个文件加载进内存。这个思路跟Java里解析XML的SAX完全一致，只是换成了专门处理Excel单元格结构的回调接口。

这篇内容适合谁？如果你在用Apache POI的XSSFSheetXMLHandler、EasyExcel这类基于事件模型的工具，或者正打算处理动辄几十万行的Excel数据，这篇文章能帮你少填不少坑。

1. 内容整体设计与思路拆解

1.1 为什么大Excel必须走SAX路线

Excel的xlsx文件本质上是个ZIP压缩包，里面装着多个XML文件，工作表内容存放在xl/worksheets/sheet1.xml这样的路径下。既然是XML，就有两种读取方式：DOM是先把整个XML树读进内存再操作，SAX则是流式扫描，遇到开始标签、文本内容、结束标签就触发对应回调。

放到Excel解析这个场景里，DOM方式需要把整张表的所有单元格对象全部建出来放进内存，一列一列、一行一行地占着堆内存。十万行、每行三十列的数据，光单元格对象就是三百万个，再加上样式、字符串驻留这些开销，JVM堆内存设个1GB都未必够用。而SAX方式是读到一行就回调一次，处理完这行数据就可以立刻丢掉引用，内存占用基本恒定，不会随文件行数线性增长。

我自己实测过一个对比：同样解析一个43MB的xlsx文件（大约28万行、20列），DOM方式在512MB堆内直接OOM，换成SAX事件解析后，Full GC次数明显减少，峰值堆内存大约在150MB左右，解析耗时从将近三分钟压缩到四十多秒。这就是SAX路线不可替代的价值。

1.2 事件模型的核心设计思想

把xlsx的sheet1.xml简化一下，大概长这样：

<sheetData> <row r="1"> <c r="A1" t="s"><v>0</v></c> <c r="B1"><v>100</v></c> </row> <row r="2"> <c r="A2" t="s"><v>1</v></c> <c r="B2"><v>200</v></c> </row> </sheetData>

SAX解析器会沿着这些节点依次触发事件：遇到<row>触发行开始，遇到<c>触发单元格事件，遇到</row>触发行结束。Excel解析框架再把这一层XML事件包装成startRow、cell、endRow这样的回调，让开发者不用直接跟XML打交道，只关心业务层面的行和单元格。

这种设计的核心思想是“边读边抛、抛完就忘”。框架把每个单元格的引用、内容、样式ID依次传给你，你的回调逻辑处理完了，框架立刻继续往下一个节点走，不会把已经读过的数据缓存起来。开发者只需要在回调里决定哪些数据要留、哪些数据不用管，主动权完全在自己手里。

1.3 工具选型：POI的事件API与EasyExcel的取舍

提到Java解析Excel，绕不开Apache POI。POI提供了一套完整的DOM式API（XSSFWorkbook + Sheet + Row + Cell），也提供了基于SAX的事件解析API（XSSFSheetXMLHandler配合SheetContentsHandler接口）。

EasyExcel则是阿里开源的一个封装层，底层仍然基于POI的SAX解析，但对外暴露了更简单的AnalysisEventListener接口。两者的区别在于：POI的事件API更底层，控制力最强，但要求开发者理解XML事件模型、自己管理共享字符串表；EasyExcel把所有底层细节藏起来了，你只需要关注invoke（解析到一行数据）和doAfterAllAnalysed（全部解析完成）这两个方法。

我的经验是：如果只是做常规的大文件导入，EasyExcel够用且高效；如果要做定制化处理，比如精确控制每一列的格式、处理特殊单元格类型、对接自定义样式策略，直接用POI的事件API更灵活。后面我会用两个框架分别对照讲解回调机制，这样无论你用的是哪个都能对上号。

2. 核心细节解析与实操要点

2.1 startRow、cell、endRow的执行顺序

先说结论，这个顺序是固定且严格嵌套的：

1. 到达某一行的起始标签时，触发startRow(int rowNum)，此时只知道这一行的行号，还不知道行内有什么内容。
2. 接着按该行内单元格在XML中出现的顺序，逐个触发cell(...)回调。有多少个有效单元格，就触发多少次。
3. 到达该行结束标签时，触发endRow(int rowNum)，标志这一行所有单元格已经全部处理完毕。

用POI的SheetContentsHandler接口来展示，核心代码长这样：

public class SheetHandler implements XSSFSheetXMLHandler.SheetContentsHandler { private int currentRow = -1; private int currentCol = -1; @Override public void startRow(int rowNum) { // 一行开始，rowNum是0-based行号，即Excel行号减1 currentRow = rowNum; currentCol = -1; System.out.println("开始处理第 " + (rowNum + 1) + " 行"); } @Override public void cell(String cellReference, String formattedValue, XSSFComment comment) { // 每触发一次，代表读取到一个单元格 // cellReference是类似 "C5" 这样的坐标 // formattedValue是已经格式化成字符串的值 currentCol++; System.out.println("单元格 " + cellReference + " -> " + formattedValue); } @Override public void endRow(int rowNum) { // 一行结束，可以在这里把整行数据写入数据库或者List System.out.println("第 " + (rowNum + 1) + " 行处理完毕"); } }

这里特别提醒一个新手容易搞混的点：startRow/endRow的参数是0-based的行号，而cell回调里拿到的cellReference是Excel风格列号+行号（例如A1、C5）。也就是说，startRow(2)表示的是Excel的第三行，而传进来的cellReference如果包含3则代表Excel第三行，两者不要混着用。

2.2 单元格回调的触发频率与空白格的坑

cell回调是按XML中实际存在的<c>节点触发的，不是按连续的列逐个触发。这就带来一个很经典的问题：一行中跳过的空列（比如A列有值、D列有值，B/C为空），XML里根本不会出现对应单元格节点，因此cell回调不会被触发。

先看一个实际例子，Excel里第一行数据是：A1 = "订单号"，D1 = "金额"，B1和C1是空的。对应的XML可能是：

<row r="1"> <c r="A1" t="s"><v>0</v></c> <c r="D1"><v>1000</v></c> </row>

SAX解析后，cell回调只会触发两次：一次A1，一次D1。如果你的业务代码假设“每行一定有连续N列数据”，按currentCol累加去对齐列位置，第4列的数据会被错放到第3列的位置。

针对这个坑，有两个标准解决办法：

• 方法一：通过cellReference解析列索引，而不是依赖回调次数自增。
• 方法二：解析之前，对sheet做一次“空列检查”，确认数据真的没有跳过空列。

EasyExcel的做法更宽容一些：它内部有自己的空值处理逻辑，如果某列在Excel里是空白，invoke读到的对应字段会是null，不会造成后续数据错位。这也是EasyExcel能快速上手的原因之一。

2.3 endRow之后必须做什么

endRow是所有行内单元格处理完毕的信号，这也是你做“行级聚合”最安全的位置。为什么这么说？因为在这个回调触发之前，框架仍有可能再往当前行追加单元格数据（虽然实际XML结构里不会，但逻辑上要等</row>闭合标签出现，行数据才算稳定）。

我踩过的坑是这样的：一开始图省事，在cell回调里直接把数据写进数据库，每一格一条SQL，结果一个28万行的文件，敲出了560万次插入，数据库连接池直接被打爆。后来改成在endRow里拼好整行数据再批量插入，性能提升了近二十倍。

还有个隐藏的细节：endRow触发时，你以为这行数据可以扔了？不一定。如果你在外部用一个List<String>承接了cell回调塞进来的值，一定要在endRow里把List清空或者重新new一个。否则下一行的数据会堆叠到上一行后面，越攒越多，最终一次性写在某行里，数据就全乱了。清空操作的位置必须是endRow，不是cell。

3. 实操过程与核心环节实现

3.1 基于Apache POI的完整解析实现

先搭一个基于POI事件API的完整示例。这个示例用XSSFSheetXMLHandler解析第一个sheet，并模拟把每行数据打印出来。为了把重点放在回调顺序上，我先用最简单的构建方式：

import org.apache.poi.openxml4j.opc.OPCPackage; import org.apache.poi.xssf.eventusermodel.XSSFReader; import org.apache.poi.xssf.eventusermodel.XSSFSheetXMLHandler; import org.apache.poi.xssf.eventusermodel.XSSFSheetXMLHandler.SheetContentsHandler; import org.apache.poi.xssf.model.SharedStringsTable; import org.apache.poi.xssf.model.StylesTable; import org.xml.sax.InputSource; import org.xml.sax.XMLReader; import org.xml.sax.helpers.XMLReaderFactory; import java.io.InputStream; public class SaxExcelParser { public static void main(String[] args) throws Exception { String filePath = "/path/to/large/orders.xlsx"; try (OPCPackage pkg = OPCPackage.open(filePath)) { XSSFReader reader = new XSSFReader(pkg); SharedStringsTable sharedStringsTable = reader.getSharedStringsTable(); StylesTable stylesTable = reader.getStylesTable(); // 只解析第一个sheet InputStream sheetStream = reader.getSheetsData().next(); XMLReader xmlReader = XMLReaderFactory.createXMLReader(); XSSFSheetXMLHandler handler = new XSSFSheetXMLHandler( stylesTable, sharedStringsTable, new SheetHandler(), // 自定义的行/单元格回调 false // 不需要公式计算，保留原样 ); xmlReader.setContentHandler(handler); xmlReader.parse(new InputSource(sheetStream)); } } }

注意几个参数点：

• stylesTable用于把样式ID翻译成格式类型，比如日期、数字格式。如果你需要知道某格是不是日期类型，必须把它传进去，否则拿到的是格式化后的字符串，类型判断会失准。
• sharedStringsTable是共享字符串表，xlsx里所有字符串值都存在这个表里，XML单元格节点里只存一个索引值。不传这个表，字符串列读出来全是数字索引。
• false是formulasNotResults参数。设为true时，遇到公式单元格会保留公式表达式而不是计算后的结果；设为false时，拿到的是公式计算后的值。绝大多数导入场景需要的是后者。

3.2 行拼接与批量入库的关键代码

实际业务里，我们不满足于只打印，得真正把数据接住。下面这段代码演示了用List<String>收拢行数据、在endRow里统一处理的模式，这也是避免内存暴涨的关键写法：

import org.apache.poi.xssf.eventusermodel.XSSFSheetXMLHandler.SheetContentsHandler; import org.apache.poi.ss.util.CellReference; import java.util.ArrayList; import java.util.List; public class RowCollectHandler implements SheetContentsHandler { private List<String> rowData = new ArrayList<>(); private int totalRows = 0; private static final int BATCH_SIZE = 1000; @Override public void startRow(int rowNum) { // 每行开始前，清空上一行残留数据 rowData.clear(); } @Override public void cell(String cellReference, String formattedValue, XSSFComment comment) { if (cellReference == null) { // 某些情况下单元格没有引用信息，按顺序补位 rowData.add(formattedValue); return; } // 解析列索引，确保空列也能占位 CellReference ref = new CellReference(cellReference); int colIndex = ref.getCol(); // 如果前面有空白列，先把前面的列填充为null while (rowData.size() < colIndex) { rowData.add(null); } rowData.add(formattedValue); } @Override public void endRow(int rowNum) { // 当前行数据已经完整，可以交给批量处理器 totalRows++; // 实际项目中，这里调用一个批量插入方法， // 攒够 BATCH_SIZE 行再统一入库 processRow(rowData); } private void processRow(List<String> row) { // 走JDBC Batch或者MyBatis批量插入接口 // 注意：外部传入的rowData在endRow之后还会被复用， // 所以如果要保存引用，必须new ArrayList<>(row) System.out.println("第" + totalRows + "行数据: " + row); } }

这段代码的巧妙之处在于cell回调里通过CellReference解析列索引，并用null补位。即使Excel里A列有值、C列有值、B列空白，最终rowData长度也能对齐到C列的索引，后续按位置取值不会错位。

3.3 EasyExcel版对照实现与推荐做法

如果你不想处理底层XML细节，EasyExcel看起来会清爽很多。它对外暴露的AnalysisEventListener实际上把startRow、cell、endRow封装成了“解析到一行的完整数据后调用invoke”这种模式：

import com.alibaba.excel.EasyExcel; import com.alibaba.excel.context.AnalysisContext; import com.alibaba.excel.event.AnalysisEventListener; import java.util.ArrayList; import java.util.List; public class EasyExcelDemo { public static class OrderData { private String orderId; private BigDecimal amount; // getter/setter 省略 } public static class OrderListener extends AnalysisEventListener<OrderData> { private final List<OrderData> cache = new ArrayList<>(); private static final int BATCH_SIZE = 1000; @Override public void invoke(OrderData data, AnalysisContext context) { // 每解析完一行，会调用一次这个方法 // 相当于在POI的endRow回调里拿到整行数据 cache.add(data); if (cache.size() >= BATCH_SIZE) { saveBatch(cache); cache.clear(); } } @Override public void doAfterAllAnalysed(AnalysisContext context) { if (!cache.isEmpty()) { saveBatch(cache); } } private void saveBatch(List<OrderData> list) { // 批量入库逻辑 } } public static void main(String[] args) { String fileName = "/path/to/orders.xlsx"; // 这里传入的是Listener对象，EasyExcel会复用这个监听器 EasyExcel.read(fileName, OrderData.class, new OrderListener()).sheet().doRead(); } }

EasyExcel的invoke回调机制，等价于POI里“每行结束、整合完该行所有单元格之后”的时机。它把startRow、cell、endRow这三层细节折叠成一个“行数据完成事件”，对绝大多数业务场景反而更顺手。但如果你的业务需要在行与行之间保持某种状态机（比如根据前一行的某个值决定当前行的处理逻辑），还是得回到POI事件API，通过startRow、endRow自己维护跨行状态。

4. 常见问题与排查技巧实录

4.1 日期、数字、公式单元格读出来是乱掉的

这是SAX解析Excel最常被吐槽的一点。SAX读取的是XML原始内容，日期在XML里可能存的是序列化的数字，比如44876.5。POI的XSSFSheetXMLHandler依赖StylesTable判断这个数字是否套用了日期格式，然后才能转换成人能读的日期字符串。

如果你没有正确传入stylesTable，或者EasyExcel的对应列没有声明成Date类型，读出来的日期会变成一串浮点数。排查思路很简单：先打印cellReference和formattedValue，确认是不是格式转换层出了问题。POI里可以临时把formattedValue和原始的stylesTable.getCellStyleXf(styleIndex)对照起来看，确认是格式索引对不上，还是底层样式数据缺失。

还有一个很隐蔽的问题：如果你的xlsx文件是从某些在线表格工具导出的，单元格可能带有奇怪的格式编号。这时候别强行依赖框架的自动转换，建议直接在cell回调里按列号做一次自定义格式化，把常见日期格式（yyyy-MM-dd、yyyy/MM/dd、dd-MMM-yy等）都覆盖一遍。

4.2 空行、空列导致的数据错位

空行和空列在SAX事件里是不会产生回调的。一个全是空白行的区间，XML里可能只有几行数据节点，解析到的行号会直接跳过去。这在不需要保持原表行号的时候问题不大，但如果你要记录“原始Excel第几行数据出错”，就必须自己维护一个rowNum到实际业务行的映射。

空列的错位问题更严重。我遇到过这样一份报表：第一行有表头，第2行开始数据，但某些行在中间列直接留空，XML里没有对应<c>节点。按回调次数累加列号的方式会把这些行整体左移，后续导入到数据库里错位得离谱。

解决模板在上面已经给过了：在cell回调里用CellReference解析列索引，用null补齐空隙。这属于SAX解析的标准防御姿势，我建议直接写进你的基础解析组件里，别等到出问题再补。

4.3 endRow里数据没清理，导致下一行数据叠加

这个坑我在3.3节提过一嘴，但值得单独拿出来说。看下面这段错误示范：

List<String> rowData = new ArrayList<>(); @Override public void cell(String cellReference, String formattedValue, XSSFComment comment) { // 把所有单元格数据加进同一个list rowData.add(formattedValue); } @Override public void endRow(int rowNum) { // 直接使用rowData，没清空也没新建 processRow(rowData); }

解析第一行时没问题，第二行时rowData里面还留着第一行的数据，cell回调又往里追加新数据，于是第二行变成第一行+第二行的拼接结果。实际表现就是：每解析一行，数据越来越长，最后一行积攒了全部文件的数据。

正确做法是像我在3.2小节写的那样，在startRow里rowData.clear()，或者在endRow里传入一个副本new ArrayList<>(rowData)。两种都可以，但千万别忘了这一步。

4.4 共享字符串表导致的内存压力

xlsx的字符串列会统一存到sharedStrings.xml里，SAX解析时，POI会把这个表加载进内存。如果一个Excel文件里有几百万条不重复的中文文本，这张表就能吃掉几百MB内存，SAX的低内存优势会被削弱。

遇到这种场景，我通常分两步走：

• 第一步，如果业务只关心特定几列，可以在解析前先对sheet的XML做一次轻量预扫描，跳过不需要的列节点，从源头减少SharedStringsTable里的索引读取量。
• 第二步，如果必须读全表，可以把这个表改成LRU缓存或者分批加载的定制实现，覆盖POI默认的全量加载策略。这需要继承SharedStringsTable并改写getEntryAt方法，适合文件特别大、字符串特别多的极端场景。

4.5 EasyExcel常见报错对照速查

4.6 压测数据：到底能快多少

最后给一组有参考价值的实测数据。测试文件是35MB的xlsx，25万行、15列，包含5列中文字符串、5列数字、3列日期、2列混合数据。机器配置是老款i7 + 16GB内存，JVM堆设512MB：

数据从哪来不用较真，重点是量级关系：SAX路线能扛住DOM扛不住的文件，内存占用还低一截。至于POI原生比EasyExcel略快的那几秒，通常是EasyExcel多做了一些对象映射和类型转换导致的，对业务影响不大。

5. 写在最后的一点经验

接触SAX解析这几年，我最深的体会是：回调顺序本身并不难懂，真正决定一个解析组件靠不靠谱的，是对边界情况的处理——空列补位、endRow清理、日期转换、共享字符串表的内存管理。这些细节在官方文档里往往一带而过，但实际生产环境里，它们才是让你凌晨被报警电话叫醒的元凶。

如果你想在项目里直接用SAX解析大Excel，我建议从POI事件API入手先跑通一遍回调顺序，再换EasyExcel做业务封装。这样既理解了底层机制，又能享受上层的便利。遇到内存问题时，心里也有底，知道该去哪一层排查。

以后再有人说“SAX解析Excel很复杂”，你可以直接把这篇甩过去：不复杂，就是startRow开头、cell逐个来、endRow收尾，搞明白这三个回调的职责和时机，大文件解析这块就稳了。