夜雨聆风做企业级后台开发，Excel 导入导出永远是绕不开的需求。运营导出活动名单、财务拉取对账明细、仓库批量更新库存…… 功能看似普通，可一旦数据量从几千行涨到几十万、上百万，问题就会集中爆发：接口超时无响应、服务频繁Full GC 甚至OOM、数据库被全表扫描拖垮核心业务，导入出错还定位不到具体行列。
很多团队上手就用 EasyExcel，觉得靠它就能搞定大文件场景。但线上绝大多数导入导出事故，根本不是 EasyExcel 本身的问题，它只解决了文件读写环节的内存开销，至于异步任务、数据库批处理、错误反馈、限流隔离这些工程问题，一样都不会自动解决。
今天我们从底层原理到生产落地，把 EasyExcel 百万级数据处理的完整方案讲透。
源码地址： https://github.com/alibaba/easyexcel
一、吃透底层：EasyExcel到底靠什么解决大数据内存痛点
很多人用了很久 EasyExcel，只知道它「省内存、适合大文件」，却不清楚它到底做了什么优化。要理解它的核心优势，得先从传统 POI 的痛点说起。
1.传统POI的内存困境：DOM模型的天然缺陷
我们常用的XSSFWorkbook（处理 xlsx 格式）属于 POI 的「用户模型」，本质是DOM树结构：它会把整个Excel 文件的所有Sheet、行、单元格、样式全部解析加载到内存中，形成一棵完整的对象树。
这种模式的问题非常明显：
对象膨胀严重：一个单元格在内存中对应Cell、CellStyle、CellValue等多个对象，数据量越大，内存占用呈指数级上升；
全量加载才能操作：必须等整个文件解析完成，才能开始业务处理，大文件场景下内存峰值极高。
POI 官方其实也提供了 SAX 事件驱动的读取模式，但是原生 API 极其繁琐，需要开发者手动处理 XML 节点事件、类型转换、异常处理，开发成本非常高，绝大多数团队都不会直接使用。
2.读取端核心：SAX事件驱动的逐行流式解析
EasyExcel 的核心价值之一，就是对 POI 的 SAX 模式做了深度封装，让开发者用极简的 API 就能享受到流式解析的能力。
它的底层工作逻辑是：
以输入流的形式读取 Excel 文件，逐层解析 XML 节点；
每解析完成一行数据，就触发一次invoke回调，把行数据转换成 Java 对象交给业务监听器；
处理完成的行对象，不再被解析器持有，随时可以被 GC 回收。
整个过程中，内存里只保留当前行数据、批次缓存和少量解析上下文，不需要加载完整文件。百万行数据导入，内存占用可以稳定在百兆级别，不会随着数据量线性增长。
这也是为什么我们反复强调「不要在监听器里把所有行攒到一个大 List 里」，这种写法相当于把 EasyExcel 的流式优势完全废掉，退化成了传统 POI 的全量加载模式，该 OOM 还是会 OOM。
3.写入端核心：分批刷写+磁盘缓存的流式输出
很多人对 EasyExcel 的写入有误解，觉得只要用了它就自动省内存。实际上，如果你先查全量数据组装成一个大 List，再调用doWrite一次性写出，本质还是全量内存写入，和原生 POI 没有本质区别。
EasyExcel 写入端的真正优势，是支持多次分批写入+磁盘溢出缓存：
开发者可以分批查询数据，每查一批就调用一次writer.write()写入；
写入的数据会先进入内存缓冲区，达到阈值后自动刷写到输出流，释放本批次的对象内存；
大数据量场景下，底层会自动将部分数据临时写入磁盘，避免全部堆积在 JVM 内存中，最终合并生成完整 Excel。
配合数据库游标分页查询，就能真正实现「查一批、转一批、写一批、释放一批」，内存占用始终保持稳定。
4. EasyExcel三层架构拆解
从功能分层来看，EasyExcel 的架构可以分为三层，各司其职：
文件解析层：最底层，负责 Excel 文件的流式读写，屏蔽 POI 底层的复杂度，核心解决大文件的内存问题；
对象映射层：中间层，基于@ExcelProperty注解实现表头与 Java 字段的映射，自动完成类型转换、格式处理，降低开发成本；
扩展能力层：最上层，提供监听器、写入处理器、样式策略、动态表头、下拉框等扩展点，支持业务自定义逻辑。
二、生产级导入方案：异步+分批+可追溯，告别超时与OOM
百万级数据导入，最忌讳在同步接口里从头读到尾，用户等待时间长还容易超时。完整的生产级导入方案，必须做好模型隔离、分批处理、异步执行、错误反馈四个核心环节。
1.模型设计：独立Excel DTO，隔离业务实体
很多图省事的写法，直接用数据库 Entity 接收 Excel 行数据，久而久之系统字段和业务字段混在一起，模板一调整就牵连数据库结构，维护成本极高。
更合理的做法是定义独立的Excel DTO，只描述 Excel 文件里的业务字段，再通过转换层和业务实体做映射。
注意：手机号、编码类字段哪怕看起来是数字形式，也优先用String接收，避免Excel自动转科学计数法丢失精度、丢失前导零。
2.监听器实现：批次缓存是核心性能点
两个关键细节一定要注意：
监听器不能交给Spring单例管理：每次导入都要 new 新实例，通过构造方法传入业务 Bean，否则多用户同时导入时，缓存和计数器会互相污染；
传参时复制集合：把缓存数据传给业务层前，用new ArrayList<>(buffer)复制一份，再清空原缓存，避免后续修改影响业务层处理。
3.接口异步化：同步接任务，异步做执行
大文件导入，用户上传完文件，接口只做三件事：校验文件格式、保存原始文件、创建导入任务，然后立刻返回任务ID。真正的解析和落库，交给独立的异步线程池后台执行。
控制层代码：
独立线程池配置：
线程池队列千万不要设太大。队列过长只会让任务堆积，把内存和数据库压力延后爆发，不如直接拒绝，让用户错峰使用。
4.三级校验+错误报告：错在哪一目了然
导入最影响体验的不是失败，而是失败了不知道哪错了。业务人员只关心「第几行、哪个字段、为什么错、怎么改」。
生产环境建议做三级校验，兼顾性能与准确性：
基础格式校验：必填校验、长度限制、数值范围，内存内完成，不查库； 引用数据校验：类目、门店等编码是否有效，先收集本批次所有编码，批量查询后内存判断，绝不逐行查库； 业务一致性校验：批次内编码是否重复、库存是否合法等业务规则校验。
校验出的错误统一收集，最后生成带错误原因的 Excel 报告，用户下载后直接对照修改即可。
三、百万级导出方案：游标分页+异步任务，拒绝全量查询
导出比导入更容易写崩，很多人的常规写法是：先把符合条件的数据全查出来放到 List 里，再直接doWrite输出。几千行没问题，几十万行下去，内存、数据库、网络会同时扛不住。
1.核心思路：游标分页+分批写入
分页查询绝对不能用limit offset，百万级数据下，offset 越大，数据库扫描丢弃的行数就越多，性能衰减非常明显。推荐用基于主键ID的游标分页，每次查询带上次查到的最大 ID 作为游标，性能全程稳定。
2.大文件必须异步导出
四、全链路性能优化：从JVM到数据库的避坑指南
1.内存优化：别让业务代码毁了流式优势
导入时把所有行攒到一个全局大 List 里再统一处理； 导出时先selectList查全量数据，再调用 EasyExcel 写入； 生成错误报告时，一次性把所有错误明细查出来； 每一行都打印 info 日志，百万行日志会拖垮磁盘 IO 和日志系统； 把整个导入放进一个大事务里，持有大量数据库连接与锁资源。
2.数据库优化：批量写入才是性能拐点
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/demo?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true |
3.资源隔离与部署建议
线程池独立：导入、导出、核心业务各自用独立线程池，避免互相抢占； 服务独立：如果导入导出量非常大，可以把这部分能力拆成独立服务，和核心交易服务部署隔离，就算 Excel 服务打满，也不影响主业务；
五、任务治理：可观测、可追溯、可管控
两个关键细节：
进度批次更新：别每处理一行就更新一次任务表，每处理完一个批次更新一次即可，频繁更新会增加额外数据库压力；
任务幂等控制：如果用消息队列执行任务，消费者必须判断任务状态，只有待执行状态才能启动，避免重复消费导致重复导入导出。
