S04-A02 · Excel 方案选型：POI vs FastExcel

适用读者：要给"导入导出 Excel"选型的人。
前置：S04-J06（IO）。
口径：两套库的具体 API 以各自文档为准（未在本机运行）；对比维度与判据为通用经验。
覆盖旧文：A-559(614) A-430(447) = 1,061 点。
覆盖扩展：E-S04-020（流式读写与内存）。
上一篇：S04-A01 · Java 版本演进与团队基线
下一篇：S05 · 并发与 JVM（下一系列）。

1. 一句话结论

选型的决定因素不是"谁更快"，而是"文件多大、并发多少、格式多复杂"。 三条轴决定了答案：

轴	影响
文件规模（行数 × 列数）	决定能否用"全内存"模型
格式复杂度（样式/公式/图表）	决定能否用简化 API
并发与内存上限	决定是否需要流式

2. 两条路线

路线	模型	内存	格式能力
Apache POI（XSSF/HSSF）	全内存对象模型	高（大文件易 OOM）	全（样式/公式/图表/批注）
POI SXSSF（流式写）	滑动窗口写	低	中（写为主）
FastExcel（EasyExcel 系）	事件/流式 + 注解映射	低	中（常用样式支持）

关键区分：POI 的 XSSF 与 SXSSF 内存模型完全不同；很多人说"POI 吃内存"，其实说的是 XSSF（用户模型）。用 SXSSF 同样能流式写。

3. 三维对比（E-S04-020）

维度	POI（XSSF）	POI（SXSSF）	FastExcel
大文件（10 万行+）	❌ 易 OOM	✅	✅
读大文件	⚠️ 需 SAX 事件模式	—	✅ 流式读
样式/图表	✅ 全	⚠️ 部分	⚠️ 常用
学习成本	中（API 冗长）	中	低（注解）
生态成熟度	最高	高	中

判据：

需要复杂格式/图表？
├── 是 → POI（XSSF，注意内存）
└── 否 → 数据量大？
        ├── 是 → FastExcel 或 POI SXSSF
        └── 否 → 都行，选团队熟的

4. 内存与流式的三条实践（E-S04-020）

实践	说明
流式读	用 SAX/事件模式，不要一次 `WorkbookFactory.create` 整本读进内存
分页处理	读 1 万行落库一次，清空引用，再读下一批
写用滑动窗口	`SXSSFWorkbook(windowSize)`，超出窗口的行刷到磁盘

内存估算（经验式）：

XSSF 内存 ≈ 行数 × 列数 × 单格对象开销（数十字节级）
10 万行 × 20 列 ≈ 数百万格 → 数百 MB～GB 级

这条估算解释了"为什么 10 万行导出会 OOM"——不是 POI 有 bug，是选了全内存模型。

5. 迁移与回滚

场景	迁移	回滚
POI → FastExcel	注解 + 监听器改写；导出逻辑按行写	保留旧实现，按开关切换
全内存 → 流式	改读写模式，接口不变	双实现并存 1 个迭代

判据："导出的业务契约（列、格式）有没有变？" 没变 → 可灰度；变了 → 要与下游对齐。

6. 五个误区

误区	真相
"POI 都吃内存"	`SXSSF` 是流式的
"FastExcel 万能"	复杂样式/图表支持有限
"小文件也上流式"	增加复杂度，收益为零
"导入导出同一套 API"	读写模型常需分别选
"OOM 是库的问题"	多是选了全内存模型

7. 自检（架构师版）

三条决策轴分别是什么？
XSSF 与 SXSSF 的内存模型差异？
10 万行导出为什么容易 OOM？怎么算的？
什么情况下 FastExcel 反而不合适？
从 POI 迁到流式库，回滚方案怎么设计？

8. 系列收尾

S04 到此结束（18 篇）。下一系列 S05 · Java 并发与 JVM（110 卡），正好接住本系列移交的 20 张并发卡。

S04 的验收报告见 ../acceptance.md。

本篇属于系列《S04 · Java 语言核心》，架构师层第 2 篇。旧文来源：A-559/A-430；扩展点 E-S04-020。具体 API 以各自文档为准（未在本机运行）。