第二章不聊原理先把数字摆上来。这一章是全文最值得收藏的地方以后谁再说“POI 慢是慢但也没那么夸张”直接把这页甩给他。先交代测试是怎么做的不然数字没有意义。环境一句话。JDK 1.8.0_66Windows堆固定 -Xms512m -Xmx1g数据是 100 万行 × 15 列的模拟话单字段和真实话单一致手机号、通道、状态、时间戳这些。三个方案用同一份数据随机种子固定成同一个每方案各跑 3 次取中位数计时用 System.nanoTime内存和 OOM 单独记录。取中位数是为了防 JIT 和 GC 抖动单次跑忽快忽慢取中间那次最稳。结果是这样的。方案耗时中位数峰值内存是否 OOMXSSFWorkbook常规写法OOM3/3 次890MB是SXSSFWorkbook窗口 10022.4 秒301MB否Apache Fesod批量流式24.1 秒352MB否三行数据每行都有话说。第一行XSSFWorkbook 常规写法3 次全部 OOM一次都没写成连“差点爆”都算不上。峰值内存冲到 890MB1G 的堆没扛住。100 万行 15 列1500 万个单元格常规写法在内存里把它们全建出来堆就没了。第二行SXSSFWorkbook22.4 秒301MB。内存只有常规写法的三分之一而且跑完了。差别在流式只保留一个窗口大小的行剩下的落盘。第三行Apache Fesod24.1 秒352MB。速度跟 SXSSF 基本相当内存略高一点。它赢的地方在 API注解加一行调用就能写EasyExcel 的项目换过来几乎零成本。新项目直接用 Fesod老项目不想动依赖就上 SXSSF都行。这组数字我跑了好几遍量级一直稳定。想自己复现的也不难测试脚本我整理好了评论区留个言我把脚本和说明发你。同样的数据常规写法直接爆流式写法 22 秒完事差别到底在哪第三章把 POI 三种 Workbook 的内存模型拆开看。