我最早系统性整理 Apache POI，是因为一个后台系统的导出功能。业务方要按天导出订单明细，数据量从几千行涨到了几十万行，原来的方案是 JDBC 直查再拼 CSV，遇到带公式、多 Sheet、合并单元格的模板就直接歇菜。后来换了 Apache POI，才把这一整块啃下来。

这篇笔记不是官方文档的翻译，是我从零学 POI 到能在生产环境里稳定跑导出任务的过程记录。内容包括三套 API 的选型逻辑、读写 Excel 的完整链路、大数据量导出的内存边界，还有一堆我实际踩过、排查过的坑。适合刚接触 POI 的后端同学，也适合写过一些 POI 但没系统梳理过内存模型的人。

1. 先搞清楚一个问题：后端为什么绕不开 POI

1.1 Excel 是一种“非正规”的数据格式

后端工程师日常打交道的数据格式，无非 JSON、XML、CSV 这类纯文本。但现实世界里，业务方要的往往是 Excel：运营要看透视表，财务要留公式，领导要带格式的报表。你不可能要求业务方去解析 CSV，只能后端想办法生成他们能直接打开的.xlsx。

Apache POI 就是干这个的。它是 Java 生态里最老牌的处理 Office 文件的开源库，能读写 Excel、Word、PPT，后端场景里 90% 的需求集中在 Excel。POI 之所以叫“POI”，全称是 Poor Obfuscation Implementation，这名字透露着早期逆向工程 Microsoft 文件格式的草莽气质，但它的能力很扎实。

1.2 POI 能做什么，不能做什么

先说能做的：

• 创建全新的.xls和.xlsx工作簿，写入数据、设置样式、合并单元格。
• 读取现有模板文件，在指定位置填充数据。
• 解析用户上传的 Excel，把数据映射到业务对象。
• 操作图表、批注、数据透视表、条件格式，甚至嵌入图片。
• 处理公式，包括让 Excel 打开文件时重新计算结果。

不能做的，也要心里有数：

• 它不是报表引擎。复杂的行列合并、动态分组、多级表头，需要你自己写逻辑，POI 只提供底层能力。
• 它不是数据库。把几十万行数据一次性塞进一个 Sheet，POI 能抗住，但内存会很难看。
• 它不能“完美”渲染那些带复杂宏、ActiveX 控件的文件，这类文件本身就不是开放格式。

1.3 选型时的全局视角

学习 POI 之前，我建议你先在脑子里建立一个坐标系：POI 是底层基础库，直接操作对象模型；也有一些第三方封装简化了导入导出的样板代码，但底层用的还是 POI。我在实际项目中的感受是，简单需求用封装库确实快，一旦涉及模板复杂样式、大数据量滑动窗口、自定义公式求值，还是得回到 POI 本身。

所以这篇笔记的定位很明确：把 POI 的底子打扎实，再往上谈什么封装都不慌。

2. 三种 Workbook 的内存模型差异，决定选型方向

POI 最核心的入口是Workbook接口。它有三个实现类：HSSFWorkbook、XSSFWorkbook、SXSSFWorkbook。很多人第一次接触 POI 时根本分不清这三个的区别，直接 new 一个就开干，等到大数据量导出时内存爆掉才回头研究。这里我一次性讲透。

2.1 HSSFWorkbook：处理旧世界的 .xls

HSSFWorkbook 对应 Excel 97-2003 格式，文件后缀是.xls。它的底层是把整个工作簿的二进制结构完整加载到内存里操作。

特点：

• 最大行数限制是 65536 行，列数限制是 256 列。
• 内存占用相对较小，因为数据结构更紧凑。
• 如果你不需要兼容老版本 Office，新项目不建议用它。

我当时接手过一个老系统，导出模板是 2003 年存下来的.xls，业务方不允许换格式，只能用 HSSFWorkbook 处理。本身数据量不大，用起来没问题。但你要知道，一旦哪天数据量突破 65536 行，它会直接抛异常，因为这是文件格式的天花板，不是 POI 的限制。

2.2 XSSFWorkbook：新版 .xlsx 的正统实现

XSSFWorkbook 对应 Office 2007 以后的.xlsx格式，底层是 OOXML 规范——其实就是一个 zip 包，里面装着一堆 XML 文件。

这个实现的问题在于，它是DOM 式的内存模型：读一个文件时，把整个 XML 解析成对象树挂在内存里；写文件时，也是先把所有数据攒在内存，最后一次性写到磁盘。

我做过一个测试，用 XSSFWorkbook 往 Excel 里写 20 万行、每行 20 列，写完以后 JVM 堆内存的占用能到 1GB 以上。原因是每一个单元格都是一个 Java 对象，每个对象有几十个字段，加上行列索引、样式引用、共享字符串表，内存开销非常夸张。

2.3 SXSSFWorkbook：流式写入的救命方案

SXSSFWorkbook 是 XSSFWorkbook 的流式版本，从 POI 3.8 开始提供。核心思路是滑动窗口：内存里只保留最近的 N 行，更早的行一旦写入磁盘就从内存中移除。

所以我当时做大数据量导出，选型思路就一句话：

数据量小、格式简单用 HSSF；数据量中等但需要新特性用 XSSF；数据量大且只需要写入用 SXSSF。

SXSSF 有个天生的限制：它只能写，不能读。而且它不保留所有行对象，写完以后想再回头修改前面的单元格是不行的。所以 SXSSF 适合“一次性生成新文件然后下载”的场景，不适合“读模板再修改”的场景。

2.4 一张表看清三个 API 的差异

提示：SXSSF 底层还是 XSSF，它生成的也是一个标准 .xlsx 文件。只是它在写入过程中没有把所有行都装在内存里。

3. 环境搭建：依赖版本和第一个能跑的 Demo

3.1 模块化 jar 包，别一股脑全引入

Apache POI 从 3.15 版本开始把 jar 包拆得比较细，核心模块包括：

• poi：处理.xls，依赖它必带 HSSF。
• poi-ooxml：处理.xlsx，包含 XSSF 和 SXSSF。
• poi-ooxml-schemas：OOXML 格式的 XML Schema 定义，XSSF 运行时的强依赖。
• poi-scratchpad：一些预览类的辅助功能，不常用。

我之前见过一个项目，把整个 POI 全家桶都引进来，后来发现poi-ooxml已经传递依赖了poi和poi-ooxml-schemas，根本不用重复声明。所以按需引入就行。

如果是 Maven 项目，最简配置是这样：

<dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>5.2.5</version> </dependency>

注意，POI 5.x 要求 JDK 8 以上，我用的是 JDK 11。如果你还在用 JDK 7，只能退到 POI 4.x。另外 POI 依赖了 Apache XMLBeans 和 Commons Compress 等公共库，Maven 会自动传递，一般不用手动管。

3.2 版本怎么选

我个人的建议是：新项目直接上 POI 5.x，因为 4.x 和 5.x 在 API 上基本兼容，但 5.x 修复了很多内存泄漏和并发问题。如果你要处理的是xls老格式，POI 5.x 依然支持，没有断崖式删除旧功能。

还有一个容易被忽略的点：如果你的项目里同时有别的库也依赖了 XMLBeans，比如某些报表组件，版本冲突会非常恶心。我遇到过一次，XMLBeans 被覆盖成旧版本，运行时报NoSuchMethodError，排查了很久才发现是依赖树打架。遇到这种问题，先看mvn dependency:tree。

3.3 第一个 Demo：写出一个最简单的 Excel

环境准备好以后，先跑一个最小示例验证链路通不通。下面这段代码生成一个包含表头和两行数据的.xlsx：

import org.apache.poi.ss.usermodel.*; import org.apache.poi.xssf.usermodel.XSSFWorkbook; import java.io.FileOutputStream; public class FirstPoiDemo { public static void main(String[] args) throws Exception { try (Workbook workbook = new XSSFWorkbook()) { Sheet sheet = workbook.createSheet("订单"); Row header = sheet.createRow(0); header.createCell(0).setCellValue("订单号"); header.createCell(1).setCellValue("金额"); Row row1 = sheet.createRow(1); row1.createCell(0).setCellValue("ORD-001"); row1.createCell(1).setCellValue(199.99); Row row2 = sheet.createRow(2); row2.createCell(0).setCellValue("ORD-002"); row2.createCell(1).setCellValue(299.5); try (FileOutputStream fos = new FileOutputStream("demo.xlsx")) { workbook.write(fos); } } } }

这段代码包含了所有基础操作：创建Workbook、创建Sheet、创建Row、创建Cell、写入单元格、输出文件。注意try-with-resources的写法，Workbook和OutputStream都能自动关闭，避免文件句柄泄漏。

跑完以后打开生成的demo.xlsx，看到表头和两行数据，说明环境完全通了。

提示：Row和Cell的索引都是从 0 开始的。第 1 行是createRow(0)，第 A 列是createCell(0)。

4. 读写 Excel 的核心操作拆解

4.1 读取 Excel 的完整链路

读取文件比写入更容易踩坑，因为你面对的是用户上传的未知内容。以下是一个完整的读取流程：

import org.apache.poi.ss.usermodel.*; import java.io.InputStream; import java.nio.file.Files; import java.nio.file.Paths; public class ReadExcelDemo { public static void main(String[] args) throws Exception { try (InputStream is = Files.newInputStream(Paths.get("demo.xlsx")); Workbook workbook = WorkbookFactory.create(is)) { Sheet sheet = workbook.getSheetAt(0); for (Row row : sheet) { for (Cell cell : row) { String value = getCellValue(cell); System.out.println("第" + (row.getRowNum() + 1) + "行, 第" + (cell.getColumnIndex() + 1) + "列: " + value); } } } } private static String getCellValue(Cell cell) { switch (cell.getCellType()) { case STRING: return cell.getStringCellValue(); case NUMERIC: if (DateUtil.isCellDateFormatted(cell)) { return cell.getDateCellValue().toString(); } return String.valueOf(cell.getNumericCellValue()); case BOOLEAN: return String.valueOf(cell.getBooleanCellValue()); case FORMULA: return cell.getCellFormula(); case BLANK: return ""; default: return cell.toString(); } } }

这里有个关键点：cell.getCellType()在旧版本里叫getCellTypeEnum()，POI 4.0 以后改成了直接返回枚举。如果你用的老版本，API 名字会不一样。

DateUtil.isCellDateFormatted(cell)是判断单元格是否为日期格式的关键。Excel 里的日期本质上是数字，但带有日期格式，如果不判断，你读出来的会是一串浮点数，比如45234.0。这个细节排名在我个人“POI 十大坑”的前三名。

4.2 写入 Excel 与单元格类型控制

写数据时，setCellValue有很多重载，不同参数对应不同单元格类型：

Cell cell = sheet.createRow(0).createCell(0); cell.setCellValue("字符串"); // STRING 类型 cell.setCellValue(100); // NUMERIC 类型 cell.setCellValue(3.14159); // NUMERIC 类型 cell.setCellValue(true); // BOOLEAN 类型 cell.setCellFormula("SUM(A1:A10)"); // FORMULA 类型

有一个容易迷惑的点：调用setCellValue(100)，写进去的是一个 double。也就是说，整数 100 在底层也是以浮点数的形式存储的。当你读回来时，getNumericCellValue()返回的是100.0。

如果业务上必须存成整数，需要设置单元格的数字格式，并且后续读取时自己处理小数位。比如用DataFormat把单元格格式设置为0（整数格式），显示上是整数，但底层值依然是 double。

4.3 合并单元格与基本样式

合并单元格用sheet.addMergedRegion，参数是一个CellRangeAddress：

CellRangeAddress region = new CellRangeAddress(0, 0, 0, 3); sheet.addMergedRegion(region);

这行代码把第 1 行第 A 列到 D 列合并成一个单元格。合并以后，只有左上角那个单元格有值，其他单元格在读取时返回BLANK。这是一个非常经典的坑，市面上很多用户在合并单元格上读取数据错位，就是没理解这个机制。

样式设置集中在CellStyle上：

CellStyle style = workbook.createCellStyle(); Font font = workbook.createFont(); font.setBold(true); font.setFontHeightInPoints((short) 12); style.setFont(font); style.setAlignment(HorizontalAlignment.CENTER); style.setVerticalAlignment(VerticalAlignment.CENTER); Cell headerCell = sheet.createRow(0).createCell(0); headerCell.setCellValue("标题"); headerCell.setCellStyle(style);

写样式时有两点经验。第一，同一个CellStyle对象可以复用于多个单元格，尽量别每建一个单元格就createCellStyle()一次，大量重复会造成内存浪费。第二，字体的高度单位是磅（point），不是像素，setFontHeightInPoints((short) 12)对应的是 12 号字，数字类型是short不是int，强转别漏。

5. 大数据量导出：SXSSF 的滑动窗口与内存边界

5.1 先理解滑动窗口机制

SXSSF 的核心是SlidingWindow机制。它维护一个窗口大小，默认值是 100。也就是说，当你写到第 101 行时，前 1 行就会被刷新到磁盘并从内存中移除；写到第 102 行时，第 2 行被移除。内存里始终只保留最近的 100 行。

这样做的代价是：一旦行被刷出窗口，你再也无法通过sheet.getRow(i)拿到那个行的对象。所以 SXSSF 的设计哲学就是“写完拉倒”，它不给你回头修改的机会。

创建方式有两种：

// 方式一：指定窗口大小 SXSSFWorkbook workbook = new SXSSFWorkbook(100); // 方式二：默认窗口大小 SXSSFWorkbook workbook = new SXSSFWorkbook();

窗口大小的选择直接决定内存峰值。窗口越小，内存占用越低，但是频繁的 flush 会带来额外的磁盘 I/O，性能下降。窗口越大，内存越高，I/O 次数变少，写入越快。需要根据实际机器内存来平衡。

5.2 大数据量导出的标准姿势

我整理了一个可以复用的实操框架，核心思想是：分批查数据，逐行写，不要一次性把全量数据 Load 进内存。

import org.apache.poi.ss.usermodel.*; import org.apache.poi.xssf.streaming.SXSSFWorkbook; import javax.servlet.http.HttpServletResponse; import java.io.IOException; import java.io.OutputStream; import java.time.LocalDate; import java.time.format.DateTimeFormatter; public class SxssfExportDemo { private static final int ROW_ACCESS_WINDOW_SIZE = 500; public void exportOrders(HttpServletResponse response) throws IOException { // 告诉浏览器这是一个需要下载的文件 response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); String fileName = "订单导出_" + LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE) + ".xlsx"; response.setHeader("Content-Disposition", "attachment; filename=" + fileName); try (SXSSFWorkbook workbook = new SXSSFWorkbook(ROW_ACCESS_WINDOW_SIZE); OutputStream out = response.getOutputStream()) { Sheet sheet = workbook.createSheet("订单明细"); // 写表头 String[] headers = {"订单号", "客户名称", "创建时间", "商品数量", "订单金额"}; Row headerRow = sheet.createRow(0); for (int i = 0; i < headers.length; i++) { headerRow.createCell(i).setCellValue(headers[i]); } // 业务侧分批获取数据，每次查 5000 条 int batchSize = 5000; int pageNum = 0; int totalRowIndex = 1; while (true) { // 这个方法代表从数据库或远程接口取一页订单数据 List<OrderDTO> batch = orderService.pageQuery(pageNum, batchSize); if (batch == null || batch.isEmpty()) { break; } for (OrderDTO order : batch) { Row row = sheet.createRow(totalRowIndex++); row.createCell(0).setCellValue(order.getOrderNo()); row.createCell(1).setCellValue(order.getCustomerName()); // 日期要用 LocalDateTime 转成字符串，避免底层是数字 row.createCell(2).setCellValue(order.getCreateTime().toString()); row.createCell(3).setCellValue(order.getItemCount()); row.createCell(4).setCellValue(order.getAmount()); } pageNum++; } workbook.write(out); } catch (Exception e) { throw new IOException("导出失败", e); } } }

不要纠结代码里的orderService，那是我示意用的业务方法，你自己的项目替换成对应的查询接口即可。重点是这里的分页查询：pageQuery(pageNum, batchSize)每次只取 5000 条，加上 SXSSF 窗口机制，内存里任何时候都没有全量订单数据。

5.3 一个典型的反例和我踩过的坑

我最开始做大数据量导出时，犯过一个典型的错误：先把全量订单 List 查出来放在内存里，再逐行写入 SXSSF。结果订单量到 30 万时，光订单列表对象就占了 700 多 MB 堆内存，导出任务直接触发频繁 GC，整个服务响应变慢。

后来我把查询改成流式分页，JVM 堆从 2G 降到 512M 也能稳定导出 50 万行。这个对比很直观地说明了：大数据量导出的瓶颈，往往不在 POI 本身，而在你把多少数据攒在内存里。

另外生产环境要注意，SXSSFWorkbook在写入过程中会创建临时文件。默认在java.io.tmpdir下，如果一个任务写一半崩溃了，临时文件可能残留。我习惯在任务的 finally 块里调用workbook.dispose()，它会清理临时文件：

SXSSFWorkbook workbook = new SXSSFWorkbook(500); try { // 写入逻辑 } finally { workbook.dispose(); }

很多同学只知道close()，不知道流式版本还有个dispose()，这两个方法都要调用。close()释放资源，dispose()删除临时文件，缺一个都会留隐患。

6. 日期、数字精度、公式：三个高频问题

6.1 日期格式：Excel 里的日期是一串数字

Excel 的日期底层是自 1900 年 1 月 0 日以来的天数，所以 45000 可能代表某一天，具体含义取决于单元格的显示格式。POI 写入日期时，如果直接setCellValue(new Date())，单元格底层存储的是这个数字，但如果没有设置日期格式，Excel 打开后会显示成一个很大的数字，而不是日期。

正确的写入方式是：

CellStyle dateStyle = workbook.createCellStyle(); CreationHelper creationHelper = workbook.getCreationHelper(); dateStyle.setDataFormat(creationHelper.createDataFormat().getFormat("yyyy-MM-dd HH:mm:ss")); Cell cell = row.createCell(0); cell.setCellValue(new Date()); cell.setCellStyle(dateStyle);

这里有两个要点：setDataFormat设置的是显示格式字符串，它必须和cell.setCellValue(new Date())配合使用，否则日期还是“裸数字”。另外不同区域环境的日期格式可能有差异，建议用yyyy-MM-dd HH:mm:ss这种国际通用的格式。

6.2 数字精度：double 不只是显示问题

POI 的数值单元格默认用 double 存储。你setCellValue(0.1)再setCellValue(0.2)，可能显示没问题，但通过公式求和或程序读取时，浮点误差会冒出来。比如 0.1 + 0.2 在二进制浮点里并不等于 0.3。

我处理金额字段的标准做法是：在业务层就用BigDecimal，写入时转成 double 是必要的，因为 POI 没有 BigDecimal 的 setter。但读取时，尤其是从 Excel 读取后再做金额计算，我会用BigDecimal.valueOf(cell.getNumericCellValue())，而不是new BigDecimal(cell.getNumericCellValue())，后者会带上二进制浮点的尾数噪声。

6.3 公式：写入公式后不计算怎么办

POI 可以给单元格写公式，例如setCellFormula("SUM(B2:B10)")。但这里有个典型问题：你用 POI 生成的文件，Excel 打开后公式区域可能不计算结果，显示为 0 或空的占位符。

原因在于 POI 写入公式时只写了公式字符串，没有计算并缓存结果。Excel 打开时需要触发一次重算。我是用下面的方式强制它刷新：

// 方案一：设置工作簿在打开时重新计算公式 workbook.setForceFormulaRecalculation(true); // 方案二：写入公式时同时设置单元格的“计算后结果”缓存 // 这需要你自己调用 FormulaEvaluator 先求值再写入

setForceFormulaRecalculation(true)是最省事的方案，Excel 打开文件时看到这个标记会自动执行一次全部公式计算。缺点是用户打开文件时会有短暂等待，数据量很大时尤其明显。

如果你不想在用户端触发重算，另一个思路是自己在服务端用FormulaEvaluator求值，把结果写入单元格缓存，但公式仍然保留：

FormulaEvaluator evaluator = workbook.getCreationHelper().createFormulaEvaluator(); for (int i = 1; i <= sheet.getLastRowNum(); i++) { Row row = sheet.getRow(i); Cell cell = row.getCell(5); // 假设公式在第 6 列 if (cell != null && cell.getCellType() == CellType.FORMULA) { evaluator.evaluateFormulaCell(cell); } }

evaluateFormulaCell会计算并缓存结果，但 Excel 打开后依然能看到公式。这个方案的开销较大，适合行数可控的场景，比如几千行的报表，不适合几十万行的导出。

有一个更隐蔽的坑：setForceFormulaRecalculation(true)对某些 Excel 版本不生效，具体表现是旧版本打开还是 0。我后来改用直接调用FormulaEvaluator求值并写缓存，同时加上setForceFormulaRecalculation(true)双保险。代价是导出时间多了一点，但能保证结果正确。在生产环境里，“结果正确”永远比“导出更快”重要。

7. 实际踩坑记录：不亲历很难想到的细节

7.1 读取 Excel 时行数判断的陷阱

很多新手读 Excel 时喜欢用for (int i = 0; i <= sheet.getLastRowNum(); i++)。这个写法在大部分情况下没问题，但你要是遇到一个“中间有整行被删除”的文件，getLastRowNum()返回的是最后一行有数据的行号，中间会有很多getRow(i)返回null的情况。

我见过有同事没判空，直接在row.getCell(0)上抛了 NullPointerException，线上监控立刻报警。正确的做法是拿到Row后先判空，或者直接用迭代器：

// 判空写法 Row row = sheet.getRow(i); if (row != null) { // 处理 } // 或者用迭代器，自动跳过空行 for (Row row : sheet) { // 处理 }

7.2 合并单元格读取时数据错位

我在做导入功能时踩过一个坑：模板里表头有两处合并单元格，我用 POI 读取时，合并单元格的空白位置影响了数据映射的列索引。

比如第 1 行合并了 A:D 列，但第 2 行开始是独立单元格。我用第 1 行来定位表头，遍历时得到 4 个 Cell，其中 3 个是BLANK，导致我把表头索引搞错位。

解决方案是单独维护一张表头映射表，或者在读取时用sheet.getMergedRegions()获取合并区域，判断当前单元格是否在某个合并区域内，如果是，去左上角单元格取值。

for (CellRangeAddress region : sheet.getMergedRegions()) { if (region.isInRange(rowIndex, colIndex)) { Cell firstCell = sheet.getRow(region.getFirstRow()).getCell(region.getFirstColumn()); // 取到合并区域的真实值 } }

7.3 大数据量导出时的内存溢出排查链路

有一次，一个定时导出的任务频繁 OOM。我当时不在现场，后来看监控大盘，发现堆内存呈锯齿状攀升，每次 GC 后都能恢复，但 GC 越来越频繁，最终在导出第 35 万行时 OOM。

排查过程是这样的：

1. 先确认是不是 POI 的问题。把 SXSSFWorkbook 的窗口调到了 100，理论上内存不应该被 POI 吃满。
2. 再怀疑业务查询。给分页查询加日志，确认每页返回的数据量正常，没有一次性把 35 万行全部加载。
3. 最后看内存泄漏。发现导出任务用的是线程池里的常驻线程，Workbook 关闭时没有调用dispose()，临时文件不释放，而且每个任务还持有了一些业务对象的引用，导致上一任务的内存无法被完全回收。

修复方案很简单：finally里调用dispose()，同时确保业务对象及时置空。

排查这件事花了半天，但让我深刻理解了 SXSSF 的“内存边界”不止在 POI 内部，还在你整个调用链的资源管理。

7.4 并发导出时的工作簿隔离

如果你把 POI 用在 Tomcat 线程池里并发处理多个导出请求，要特别注意：同一个 Workbook 实例不能被多个线程同时写入。POI 的Workbook不是线程安全的。

我当时的做法是每个请求创建独立的工作簿，互不共享。如果多个请求读取同一个模板文件，就对模板流做隔离，而不是共享同一个Workbook对象。模板本身是.xlsx文件字节流，每次读取都new XSSFWorkbook(inputStream)，慢一点，但安全。

另外一个隐藏问题是字体和样式对象。Font和CellStyle是从Workbook创建的，它们也绑定在 Workbook 上。如果在多线程里共享同一个Workbook的样式对象，也会产生竞态。我后来养成了一个习惯：凡是并发导出相关的代码，都加上ThreadLocal或按请求创建实例，绝不做跨线程的 POI 对象共享。

8. 一些后续值得深入的方向

学完 POI 的基础后，如果你的项目里经常要做报表，有几个方向值得继续挖：

第一，模板填充模式。在 Excel 里预先设计好样式、公式、数据区域，POI 只负责填充值，能节省大量样式代码。实践中我用过这种方案：用 XSSFWorkbook 读取模板，定位到某个 Sheet 的指定行，用sheet.shiftRows()做行扩展，然后填充数据。

第二，自定义颜色与主题。深入理解IndexedColors和XSSFColor的区别。IndexedColors是调色板索引，适合简单场景；XSSFColor可以写 ARGB 值，但要注意低版本 Excel 对颜色的兼容。

第三，SAX 模式解析超大 Excel。XSSFWorkbook读取大文件也会吃内存，POI 提供了一个基于 SAX 的XSSFEventBasedExcelExtractor和XSSFReader，可以只读取内容流而不构建完整对象模型。这个我在解析用户上传的 20 万行 Excel 时用过，内存占用可以控制在 100MB 以内，代价是代码复杂度高很多。

至于要不要二开封装，我的建议是：别急着写一套自己的导出框架。先在自己的项目中把 POI 用扎实，遇到重复代码再抽象，抽象时保留控制权，不要封装到完全看不到底层 API。因为 POI 的 API 设计整体上很扁平，很多操作一两行就写完，过度封装反而增加理解成本。

我个人的学习路径是先写小 demo，再逐步增加样式、公式、大数据量，最后整理出一份适应自己业务的工具类。每次遇到新的格式需求，都回去翻 POI 的底层实现，而不是无脑套封装。这样做的好处是，下次业务方丢过来一个带合并单元格和批注的模板时，你心里已经大概能猜到 POI 会怎么处理它。