真的，我在 Java 项目里跟 Excel 打了这么多年交道，提到“用 Java 操作 Excel”，绝大多数人第一反应就是 Apache POI。而 POI 家族里出场率最高、坑也最多的，就是这个 XSSFWorkbook。今天我不打算照着官方文档念一遍 API，而是想从原理到实际踩坑，把 XSSFWorkbook 这东西掰开揉碎聊清楚，包括它为什么能吃内存、为什么处理大文件容易 OOM、日常读写怎么设计才稳，以及面试里被问烂的那几个点到底该怎么答。
这篇文章适合刚接触 POI 的新手，也适合已经用 POI 写过几个工具类、但遇到内存溢出或者文件损坏问题还没真正搞懂原因的同学。我会结合真实项目场景来讲，尽量让每个人读完都能直接照着落地。
1. XSSFWorkbook 背后到底是个什么东西
1.1 先把 POI 的“三兄弟”分清楚
Apache POI 是一个纯 Java 的开源库，用来读写 Microsoft Office 格式的文件。早期 POI 主要做的是 .xls，也就是 Excel 97-2003 的二进制格式，对应的是 HSSF 这套 API。后来 Office 2007 开始默认用 .xlsx，也就是基于 OOXML（Office Open XML）标准的格式，POI 就推出了 XSSF 这套 API。
所以你现在看到的类名其实已经暗示了它的技术路线：
- HSSFWorkbook：操作 .xls（二进制格式，Horrible Spreadsheet Format）
- XSSFWorkbook：操作 .xlsx（XML 文本格式，XML Spreadsheet Format）
- SXSSFWorkbook：XSSF 的流式版本，专门解决大数据量写入时的内存问题
你打开任何一个 .xlsx 文件，其实它就是一个 zip 压缩包。不信的话你可以把后缀改成 .zip 然后解压看看，里面会有一堆 XML 文件。XSSFWorkbook 做的事情，本质上就是把这一堆 XML 按照 OOXML 规范解析成 Java 对象，操作完再重新打包成 zip。
1.2 XSSFWorkbook 怎么跟 OOXML 对应起来
我们拿一个最简单的 .xlsx 解压开来看，它的核心结构大概是这样的：
[Content_Types].xml -- 声明各个 content type _rels/.rels -- 根级关系文件 docProps/app.xml -- 应用属性，如标题、作者 docProps/core.xml -- 核心属性，如创建时间 xl/workbook.xml -- 工作簿，定义 sheet 列表 xl/_rels/workbook.xml.rels -- 工作簿和各 sheet 的映射关系 xl/styles.xml -- 样式表，单元格样式都在这里 xl/worksheets/sheet1.xml -- 第一个工作表，真正的单元格数据 xl/sharedStrings.xml -- 共享字符串表XSSFWorkbook 加载的时候，就是由OPCPackage先把这个 zip 包打开，然后按照 OPC（Open Packaging Conventions）规范把各个 part 读取出来。XSSFWorkbook自己对应xl/workbook.xml，你调用getSheetAt(0)时，它会通过关系映射找到xl/worksheets/sheet1.xml，再由XSSFSheet解析里面的<row>和<c>节点。
这种设计的好处是解耦，每个 part 各管各的，关系清晰。坏处就是——整个文件被完整解析进内存，每个单元格、每个样式都是一个个 Java 对象，这就是后面内存爆掉的根源。
1.3 单元格对象的层级关系
我见过不少人写代码直接new XSSFWorkbook()然后在里面塞数据，但问他Row和Cell是怎么从Workbook里拿到的，会答得含糊。其实这套层级非常简单直观，跟 Excel 的物理结构完全一致：
Workbook workbook = new XSSFWorkbook(); Sheet sheet = workbook.createSheet("示例"); Row row = sheet.createRow(0); Cell cell = row.createCell(0); cell.setCellValue("Hello POI");Workbook -> Sheet -> Row -> Cell，一层套一层。在实际业务里，我们基本不会直接操作底层 XML，都是通过这套对象模型。但你要心里有数：你每一次createCell，都是在内存里 new 了一个XSSFCell对象，而这个对象内部还有CellType、样式索引、可能还有注释、超链接等附属信息。数据量一上来，内存就是这么被吃掉的。
2. 核心原理：为什么 XSSFWorkbook 容易内存溢出
2.1 从 DOM 和 SAX 的对比说起
如果你写过 Java 解析 XML，应该对 DOM 和 SAX 这两个模式有印象。DOM 是先把整个 XML 读进内存构建树结构，然后你再随便操作；SAX 是边读边触发事件，不保留整棵树，因此内存占用极低。
XSSFWorkbook 的加载逻辑本质上就是 DOM 模式。它会把整个 workbook 相关的内容全部加载成对象，包括所有 sheet、行、单元格、样式、共享字符串。这种模式的好处非常明显：你可以在任意位置随机读写，改一个单元格不影响其他部分，API 用起来极度舒适。
但代价就是内存。如果你的 Excel 有 10 万行、每行 20 列，那就是 200 万个单元格。每个XSSFCell对象再带上它的样式引用、类型信息、字符串值等等，随便算算都是几百 MB 起步。再加上共享字符串表（sharedStrings）如果很大，内存还会再飙一截。
我在一个实际项目里遇到过：从数据库导出 30 万行数据到 Excel，用原生XSSFWorkbook直接写，堆内存给了 2G 还是 OOM。后来换成SXSSFWorkbook才压下来，这个下面细说。
2.2 到底多少数据量会触发 OOM
这个问题没有标准答案，因为跟你的列数、单元格内容长度、是否带样式、JVM 堆大小都有关系。但我可以给一个大家实测下来比较有共识的参考范围：
- 1 万行、10 列以内：
XSSFWorkbook随便用，毫无压力。 - 5 万行、20 列左右：开始有内存压力，但给个 512M 到 1G 一般还能扛。
- 10 万行以上：强烈建议别用
XSSFWorkbook硬写了，考虑SXSSFWorkbook或者 EasyExcel 这类方案。
当然了，读取也是一样。如果你只是要读一个 10 万行的 xlsx，用XSSFWorkbook全量加载，内存占用也很可观。更合理的方式是用 POI 的 eventmodel（也就是 SAX 方式）配合XSSFReader去流式读取，后面的实操章节会有示例。
2.3 SXSSFWorkbook 的滑动窗口机制
SXSSFWorkbook是 XSSFWorkbook 的流式版本，它解决写入大文件问题的思路非常有意思：窗口滑动。你可以把它理解成一台只看得见当前一段数据的机器，只有窗口内的 Row 对象存在于内存里，窗口外的行会被刷到磁盘上的临时文件里，然后从内存中移除。
默认窗口大小是 100 行，意思是内存里最多只保留 100 个 Row 对象，其余的都写到临时文件了。窗口大小可以通过构造函数调：
SXSSFWorkbook workbook = new SXSSFWorkbook(200);SXSSF 写出来的文件格式仍然是标准的 .xlsx，所以用户拿到的文件没有任何区别。但它的限制也很明显：只能用写入场景，不能随机读取已有的行。你想打开一个已有文件然后往中间某一行插入数据？抱歉，做不到。这也是很多人踩坑的地方：拿SXSSFWorkbook去读模板文件，结果发现根本读不到原来的内容。
注意：
SXSSFWorkbook写完后要调用dispose()释放临时文件，否则磁盘上会残留临时文件。我见过有项目上线后服务器 /tmp 目录被撑爆的，就是这个原因。
2.4 读大文件的正确姿势：XSSFReader 与事件模式
刚才说了XSSFWorkbook读取是 DOM 模式，那 POI 其实也提供了 SAX 模式，就是XSSFReader配合SheetContentsHandler。这个方案专门用来流式读取 sheet 里的单元格数据，不构建完整对象模型，内存占用大幅下降。
核心流程是这样的：你先用OPCPackage.open(文件流)打开压缩包，然后通过XSSFReader拿到 SharedStringsTable 和每个 sheet 的输入流，再用XMLReader去解析sheet1.xml，在解析过程中通过回调把单元格数据吐出来。
这一段代码比XSSFWorkbook直接遍历要繁琐得多，而且读出来的单元格没有类型信息、没有样式、没有公式，完全要靠你自己根据t属性判断是字符串还是数字。但它能解决真实场景里“必须读一个 100MB 的 Excel”这种硬需求。
OPCPackage pkg = OPCPackage.open(inputStream); XSSFReader reader = new XSSFReader(pkg); SharedStringsTable sst = reader.getSharedStringsTable(); XMLReader parser = XMLHelper.newXMLReader(); parser.setContentHandler(new SimpleSheetHandler(sst)); parser.parse(new InputSource(reader.getSheetsData().next()));这段代码里SimpleSheetHandler需要你继承DefaultHandler自己去解析c节点，网上有很多现成的例子，但核心要点就一个：别用 XSSFWorkbook 去开大文件，用事件模式。
3. 实操：用 XSSFWorkbook 写出一个能生产级用的 Excel
3.1 引入依赖的正确姿势
Maven 项目里直接加：
<dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>5.2.5</version> </dependency>注意版本，POI 4.x 和 5.x 在部分 API 上有差异，5.x 之后HSSFColor这类类名迁移到了org.apache.poi.hssf.usermodel包下，用法略有不同。建议新项目直接用 5.x，老项目升级时重点关注CellType和DateUtil相关改动。
如果你还需要操作 Excel 的图表、VBA 之类的高级功能，可能还要额外引入poi-ooxml-full这个扩展包。大部分场景下poi-ooxml就够了。
3.2 创建带样式的工作簿
实际业务里，导出的 Excel 很少是纯数据，通常需要表头加粗、背景色、边框、列宽调整、冻结窗格等等。我用一段实际项目中比较典型的写法来演示：
try (Workbook workbook = new XSSFWorkbook()) { Sheet sheet = workbook.createSheet("订单数据"); // 设置列宽，单位是 1/256 字符宽度 sheet.setColumnWidth(0, 10 * 256); sheet.setColumnWidth(1, 30 * 256); // 创建表头样式 CellStyle headerStyle = workbook.createCellStyle(); headerStyle.setFillForegroundColor(IndexedColors.GREY_25_PERCENT.getIndex()); headerStyle.setFillPattern(FillPatternType.SOLID_FOREGROUND); headerStyle.setAlignment(HorizontalAlignment.CENTER); Font headerFont = workbook.createFont(); headerFont.setBold(true); headerStyle.setFont(headerFont); // 创建表头行 Row headerRow = sheet.createRow(0); String[] headers = {"订单号", "客户名称", "金额"}; for (int i = 0; i < headers.length; i++) { Cell cell = headerRow.createCell(i); cell.setCellValue(headers[i]); cell.setCellStyle(headerStyle); } // 冻结首行 sheet.createFreezePane(0, 1); }这里面有个小细节：setColumnWidth的单位是 1/256 个字符宽度，所以10 * 256表示这一列大约能显示 10 个字符。如果你直接写10，列宽会窄到几乎看不见，这是很多人刚开始用 POI 时容易困惑的点。
另外，样式对象CellStyle是在 Workbook 级别创建的，不是 Sheet 级别。同一个工作簿里，相同样式的单元格应该复用同一个 CellStyle 对象，不要每行都createCellStyle()一次，否则文件体积会迅速膨胀，内存也受影响。
3.3 单元格写入的坑：字符串、数字、日期、公式
单元格写入看起来简单，但里面的坑比想象中多。最典型的是日期。如果你直接cell.setCellValue(new Date())，默认格式会是m/d/yy这种样式，很不符合国内习惯。正确的做法是设置单元格格式：
CellStyle dateStyle = workbook.createCellStyle(); dateStyle.setDataFormat(workbook.getCreationHelper().createDataFormat().getFormat("yyyy-mm-dd hh:mm:ss")); Cell cell = row.createCell(3); cell.setCellValue(new Date()); cell.setCellStyle(dateStyle);再说公式。POI 写入公式用的是setCellFormula，但如果你只是写入公式而不调用求值器，这个单元格在 Excel 里打开时会重新计算，所以显示值是对的。但如果你用 Java 读取这个单元格的值，拿到的是公式字符串，而不是计算结果。这就需要FormulaEvaluator出场：
FormulaEvaluator evaluator = workbook.getCreationHelper().createFormulaEvaluator(); CellValue value = evaluator.evaluate(cell); double numericValue = value.getNumberValue();FormulaEvaluator在读取别人生成的 Excel 时也很有用。很多系统导出的 Excel 里某些列是公式，你直接用getNumericCellValue()会报错，得先判断单元格类型再决定怎么取值。
3.4 合并单元格与多级表头
合并单元格是报表需求里的常客。比如一个季度统计表，顶部一行要跨 3 列显示“第一季度”。实现方式：
sheet.addMergedRegion(new CellRangeAddress(0, 0, 0, 2));这段代码的含义是从第 0 行到第 0 行、第 0 列到第 2 列合并成一个单元格。要注意的是，合并之后你只需要给左上角的单元格赋值，其余单元格在读取时会是空值。
还有一个常见的坑：合并单元格之后如果你遍历行读取数据，只有合并区域左上角的 cell 有值，其他 cell 是 null。所以业务上解析这种报表时要做好空值处理。
多级表头说白了就是“先合并行，再合并列”。比如第一行是“订单信息”，横跨订单号、客户名称两列；第二行是具体的字段名。这种结构我一般建议先用二维数组把表格结构画出来，再写代码填充，别边写边调整，很容易乱。
3.5 大数据量写入的三种方案怎么选
如果数据量到了 5 万行以上，就不能无脑用XSSFWorkbook了。我按实际项目经验把方案分成三档：
第一档，数据量 1 万行以下，直接用XSSFWorkbook，代码简单，样式随便玩，内存没压力。
第二档，5 万到 20 万行，用SXSSFWorkbook。窗口大小按你的实际内存情况调，默认 100 就行。注意 SXSSF 对样式有限制：同一窗口内最多只能有有限数量的样式，实际上是因为样式表styles.xml是常驻内存的，样式数量过多同样会撑爆内存。所以大数据量导出时，我只用有限的几种样式，绝不对每个单元格单独设置样式。
第三档，50 万行以上，说实话不太建议用 POI 直接导 Excel 了。可以考虑先导 CSV，或者用 EasyExcel 这类基于 SAX 的框架。CSV 体积小、写入快，就是没有格式、没有多 sheet，但作为数据导出完全够用。
提示：还有一个很容易被忽略的性能杀手——频繁刷盘。
SXSSFWorkbook的行数据会写入临时文件，如果你打开了setCompressTempFiles(true)，CPU 消耗会增加但磁盘占用减少。要不要开，取决于你的服务器磁盘 IO 和 CPU 负载。
4. 高频问题排查与实战经验
4.1 内存溢出的排查清单
如果你已经被OutOfMemoryError搞到头大，按下面这个顺序排查：
- 确认是否用
XSSFWorkbook加载了超大文件。如果是，换成SXSSFWorkbook写入，或者事件模式读取。 - 看是不是样式太多导致
styles.xml巨大。统计一下你createCellStyle调了多少次，把重复样式合并。 - 看是不是共享字符串表巨大。xlsx 文件里所有字符串都会进 sharedStrings，大量重复文本会非常占内存。如果你发现字符串重复度高，可以考虑用
setCellValue时直接传枚举值或者事先去重。 - 检查是否把
InputStream包在了Workbook外面没关。POI 在读取时如果用的是WorkbookFactory.create(InputStream)，文档流关闭与否会影响内存回收，建议用完后workbook.close()。
另外我很推荐大家用jvisualvm或者arthas去看一下堆内存里到底是什么对象占了大头。很多时候猜测半天，一看快照就明白了。
4.2 为什么读出来的数字变成了科学计数法
这个几乎是 100% 会碰到的问题。Excel 单元格里的长数字，比如订单号、身份证号，在 POI 读取时默认按数字处理，如果单元格格式是“常规”，POI 读出来可能是个 double，打印出来就成了科学计数法。
解决方案不复杂，关键是要先判断单元格格式：
if (cell.getCellType() == CellType.NUMERIC) { double value = cell.getNumericCellValue(); // 如果这个单元格本来存的是文本型数字，cell.getCellType() 其实是 STRING // 所以读出来是科学计数法，大概率是源文件里存的就是数字 }如果你想彻底避免，最稳妥的做法是在判断时用DataFormatter：
DataFormatter formatter = new DataFormatter(); String value = formatter.formatCellValue(cell);DataFormatter会按照 Excel 的显示格式来格式化单元格，数字就不会显示成科学计数法了。强烈建议在解析 Excel 时统一用这个工具类。
4.3 模板填充后文件损坏
这是一个高频翻车现场：你准备了一个带格式的 xlsx 模板，用XSSFWorkbook打开，填充数据，再写出去，结果用户打开文件提示“文件已损坏，是否尝试恢复”。
这类问题大多有几个原因。一个是模板里带有图片、图表、VBA 等复杂对象，POI 对这些对象的支持不够完整，重新写出时可能丢失或写入错误数据。解决办法是模板尽量保持简单，尤其是图表这种东西，POI 支持有限，尽量避免。
另一个原因是模板里的某个 sheet 或者样式在写入时被 POI 重新计算结果后产生了不兼容。我遇到过一次，是因为模板里有一个单元格的值是公式且引用了外部数据源，POI 在求值后写出去，Excel 打开就报错。
最实用的排查技巧：用 POI 打开重写后的文件，如果 POI 自己能正常读，一般说明文件结构没问题；如果打不开，多半是模板里带了不兼容的元素。那就把模板里的高级功能拆掉，改用代码创建样式。
4.4 并发导出线程安全问题
我之前在给一个系统做报表模块时，直接用static的Workbook对象给多个用户并发导出，结果出现了一部分用户下载的文件数据串了。原因很简单：XSSFWorkbook不是线程安全的，多个线程同时操作同一个 workbook 实例，轻则数据错乱，重则直接抛异常。
解决方案两种：一是每个请求都新建Workbook实例（推荐，反正创建成本可接受），二是用 ThreadLocal 给每个线程一个独立的 workbook 实例。简单粗暴的结论就是：别共享 Workbook 实例。
4.5 面试高频题：XSSFWorkbook 和 SXSSFWorkbook 的区别
这个几乎是 Java 面试里 POI 方向的必问题。标准答法是：
- XSSFWorkbook 是 DOM 模式，一次性加载整个工作簿到内存，支持随机读写，但大数据量下容易 OOM。
- SXSSFWorkbook 是流式写入，维护一个滑动窗口，内存中只保留固定行数，超过的写到磁盘临时文件，适合大数据量写入，但不支持读取已有行，也不能随机修改。
有的面试官还会追加问一句：SXSSFWorkbook 的临时文件什么时候删除？答案是调用dispose()或者workbook.close()的时候。这两个方法底层都会清理临时文件，但如果你持有SXSSFWorkbook对象却没调用，临时文件会留在系统临时目录。
4.6 常见问题速查表
| 问题 | 原因 | 解决 |
|---|---|---|
| 写入 10 万行 OOM | XSSFWorkbook 全量加载 | 换 SXSSFWorkbook |
| 日期显示为数字 | 未设置日期格式 | createDataFormat 并 setCellStyle |
| 长数字变科学计数法 | 单元格类型是数字 | 用 DataFormatter 格式化 |
| 模板填充后文件损坏 | 模板含图表/VBA/外部引用 | 简化模板，公式求值后写死 |
| 并发导出数据串 | 共享 Workbook 实例 | 每个请求 new 一个 Workbook |
| 读取公式单元格报错 | 单元格类型是 FORMULA | 用 FormulaEvaluator 求值 |
5. 横向对比与选型建议
5.1 POI 与 EasyExcel、FastExcel 的取舍
如果你经常处理 Excel，应该知道阿里开源的 EasyExcel 这两年很火。EasyExcel 底层也是基于 POI 的，但它默认使用 SAX 模式读写，所以内存占用远低于原生XSSFWorkbook，API 也更简洁。我在实际项目中对比过：同样导出 30 万行数据，POI 的SXSSFWorkbook内存占用大约 200M 左右，EasyExcel 能做到 100M 以内，而且代码量少不少。
但 EasyExcel 也有它的局限性。它对复杂模板的支持不如原生 POI 灵活，尤其是当你需要在固定位置插入大量合并单元格、复杂样式、多级表头时，EasyExcel 反而会让你绕圈子。而原生 POI 的好处恰恰在于完整性和可控性：样式、合并、公式、批注、数据验证、图片，几乎所有 Excel 能力都能操作。
FastExcel 是 poi 的一个包装器，这个不太建议选了，维护活跃度不如 EasyExcel，而且并没有本质上的性能优势。
5.2 到底该选哪个，我的建议
我根据实际项目经验给一个比较务实的推荐：
- 如果你只是做简单的数据导出导入，数据量又大，优先考虑 EasyExcel，省事省内存。
- 如果你的需求涉及复杂报表、模板填充、样式精细控制，尤其是要做多 sheet 的复杂报表，直接原生 POI 更稳。
- 如果两者都有，可以考虑两种混用：复杂模板用 POI 处理，大数据量平面表用 EasyExcel 导出。
这里多说一句，EasyExcel 的读性能虽然好，但它的 API 抽象程度比较高，出了问题排查起来不太直观。而 POI 的报错信息往往更明确，定位问题更快。线上运维角度讲，poi 的“丑但可靠”反而是优势。
5.3 从 Python 生态反观 Java 的 Excel 处理
热搜词里也有“python写入excel”和“pymupdf to excel”，说明很多人也在用 Python 处理 Excel。Python 生态里 openpyxl 和 pandas 处理 Excel 确实非常爽，pandas 一行df.to_excel()就完成导出。但如果你在 Java 项目里，真的不建议为了导 Excel 去套一个 Python 服务，运维成本太高。
看清楚 POI 和其他方案的关系，本质上是精度和性能的权衡。Python 处理 Excel 走的是“快速分析”路线，Java 走的是“工程化集成”路线。POI 在 Java 里能跟 Spring、MyBatis、各种定时任务框架无缝整合，单这一个优势就足够让它成为 Java 后端的事实标准。
6. 实操中的一些心得体会
到最后，我想分享几个这些年积累的小经验，不一定写进文档里，但很管用。
第一，做 Excel 导入功能时，一定要对空行和多余空白字符做处理。很多用户给的 Excel 看起来只有几行数据，实际上格式刷把几千行的样式都带上了，POI 遍历时会发现row == null的情况特别多，造成解析结果里出现大量空记录。判断条件统一用row != null并且row.getPhysicalNumberOfCells() > 0。
第二，如果业务允许，导出的 Excel 尽量不用公式，直接把计算好的值写进去。这样既减少了FormulaEvaluator的使用场景，也避免不同 Excel 版本打开时公式重算导致的显示差异。
第三，处理大文件时一定要做好分页或者分批读取，不要同时在数据库查全量数据再往 Excel 里塞。我以前做过一个导出功能，数据量一大，数据库连接先被拖垮，然后才是内存问题。后来改成流式查询 + 分批写入，两个问题都解决了。
第四，不要忘了workbook.close()。这是个非常基础但容易被忽略的操作，尤其是在用连接池或者长生命周期对象时。XSSFWorkbook持有 zip 包的输入流，不关闭会占用文件句柄，在 Linux 服务器上文件句柄用光是很麻烦的。
说白了，XSSFWorkbook 本身并不神秘，就是一个把 OOXML 的 XML 文件映射成 Java 对象模型的解析器。它的上限和下限都由这个设计决定——易用而吃内存。理解这一点，你在项目里用它的思路就会清晰很多：小文件直接用，大文件换流式方案，复杂模板用完整 API，把工具用在它最合适的场景里。
上面提到的所有坑，都是我在真实项目里踩过或者帮别人排查过的。如果你也是做 Java 后端、经常跟 Excel 打交道，建议先把自己项目里导出的逻辑理一理，看看有没有还在用XSSFWorkbook硬扛大数据量的地方，趁早优化掉，省得线上爆内存的时候半夜爬起来看日志。
