在Java Web项目中实现Excel导出，核心路径是选择成熟的开源库Apache POI或阿里EasyExcel，对于数据量在十万行以上的场景，EasyExcel凭借流式处理大幅减少内存开销，是效率优先的推荐方案；若需复杂格式和公式支持，POI则更为灵活。
Java Web导出Excel：POI和EasyExcel哪个更合适？
面对库选型，常见误区是盲目追随社区热度，其实根据具体需求选,才能避免后期踩坑。
POI的传统优势与局限
POI是Apache基金会项目，支持Excel 97-2003（.xls）和2007+（.xlsx）两种格式，它提供HSSFWorkbook和XSSFWorkbook，能用Java对象完整映射Excel文档结构，业内专家指出，POI在单元格样式、图表、公式、数据验证等高级功能上依然是首选方案，但它的原生模式会将整个工作簿加载到内存，数据量稍大就容易触发OOM，为此POI推出了SXSSFWorkbook（流式写入），只保留部分行在内存，其余写到临时磁盘，但仅支持.xlsx,且对图表和公式的支持有限。
EasyExcel的轻量级设计
EasyExcel是阿里巴巴开源工具，基于POI的SAX事件模型重新封装，它默认逐行读写，写入时数据不会被缓存到完整工作簿，内存占用非常稳定，行业共识认为，EasyExcel在实际业务中更受一线开发者欢迎，尤其在金融、电商等高频导出场景，它的注解配置简单，学习成本低，缺点是仅支持.xlsx,且对复杂图表和公式的支持不如POI完善。
| 特性 | Apache POI | EasyExcel |
|---|---|---|
| 内存模式 | 普通方式全量加载，SXSSF流式可选 | 默认流式，批量写入后立即释放 |
| 格式支持 | .xls、.xlsx、图表、公式、VBA | 仅.xlsx，常用格式和样式均支持 |
| 学习曲线 | API丰富但繁杂，需要较多代码 | 简洁注解+轻量API，上手快 |
| 大文件支持 | SXSSF可处理数十万行，但需调优 | 原生支持百万级行，内存稳定 |
| 社区活跃度 | 历史久，文档全，维护持续 | 国产，中文问答丰富，更新较快 |
从对比看：新项目且数据量大优先EasyExcel；项目已用POI且需要复杂编辑继续用POI；两者也能共存,部分导出用EasyExcel快速实现。
Java Web导出Excel大文件处理方案
数据量超过万行是不少生产问题的引爆点，如果直接全表查都查不出来，更别说写文件了，正确做法是分页、流式和异步三板斧。
分页查询与流式写入
业务层必须使用分页SQL，每次读取固定行数（如5000行），利用EasyExcel的WriteHandler或POI的SXSSFWorkbook连续追加写入，务必在写入完一批后清空中间列表，否则内存仍会累积，例如使用MyBatis的游标查询（Cursor）可以在迭代时逐条处理,无需额外分页。
异步导出与临时文件
同步接口一旦数据量大必然超时，应设计异步导出：前端发送请求，后端接收后返回一个任务ID，后台线程生成Excel，完成后上传到OSS或存储到指定目录，前端轮询任务状态或通过WebSocket获得下载通知，这样用户无需等待页面转圈，文件生成过程中可以使用有意义的中间文件命名,避免下载时覆盖。
服务端配置优化
JVM堆内存要根据并发导出任务数预留，例如同时允许5个导出任务，每个峰值内存按100MB估算，则堆至少1GB，另外指定临时文件目录：-Djava.io.tmpdir=/export/tmp，防止/tmp空间被写满，Tomcat的连接超时时间也要适当定义，因为异步任务不会占用连接太久，但如果是同步大导出就需要调大connection-timeout。
Java Web导出Excel代码实现细节
只看理论不够，把代码层面的关键节点写清楚,能省去很多调试时间。
Maven依赖引入
EasyExcel最新稳定版可到Maven中央仓库查询，POI需要引入poi-ooxml，它会自动依赖poi和ooxml-schemas。
<!-- EasyExcel --> <dependency> <groupId>com.alibaba</groupId> <artifactId>easyexcel</artifactId> <version>3.3.2</version> </dependency> <!-- POI（仅当选择POI时） --> <dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>5.2.5</version> </dependency>
实体与导出方法
实体通过注解定义列顺序和表头。
@Data
public class OrderExportVO {
@ExcelProperty("订单编号")
private String orderNo;
@ExcelProperty("客户姓名")
private String customerName;
@ExcelProperty("实付金额")
private BigDecimal payAmount;
}Service层接收一个HttpServletResponse对象，获取输出流，数据不是一次性查询，而是分批从数据库读取，用EasyExcel.write(outputStream, OrderExportVO.class).sheet("订单数据").doWrite(data -> supplyNextPage())，其中supplyNextPage()返回每批数据列表，这样数据边读边写,内存不会膨胀。
下载响应设置
Controller设置：
response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet");
response.setCharacterEncoding("UTF-8");
String fileName = URLEncoder.encode("订单导出", "UTF-8") + ".xlsx";
response.setHeader("Content-disposition", "attachment;filename=" + fileName);然后获取response.getOutputStream()传递给EasyExcel，流程结束时在finally中关闭ExcelWriter（若用代码写）或SXSSFWorkbook的write流,很多损坏问题都源于未关闭资源。
Java Web导出Excel乱码与文件损坏处理
文件名乱码、内容乱码、文件打不开是常见客服反馈,排查思路要清晰。
文件名中文乱码
下载响应头Content-Disposition必须对中文进行URL编码，上面代码已经做了，若不行，有的浏览器还需要百分号编码：filename=UTF-8'' + 编码后的字符串，保守做法同时写上filename和filename。
文件打开提示损坏
- 扩展名与内容不一致：
.xlsx内容必须用application/vnd.openxmlformats-officedocument.spreadsheetml.sheet类型，不能用application/vnd.ms-excel（那个是.xls）。 - 输出流未正确关闭：在
finally
ExcelWriter.finish()或OutputStream.close()。 - 项目启动后第一次导出经常损坏：检查代码路径，排除过滤器/拦截器再次写入响应体的干扰。
- 使用代理服务器时，若输出流已被压缩或修改也会导致损坏,建议关闭Gzip或只压缩部分资源。
超时与内存溢出
java.lang.OutOfMemoryError: Java heap space最常发生在一次性把所有数据放入List再写入的阶段，使用流式写入可避免，如果并发导出多且内存仍超限，考虑限制同时导出任务数（使用信号量），超时问题在异步方案中基本解决；若必须同步,可在Nginx或网关层设置响应超时时间。
Java Web导出Excel没有银弹，选型需结合实际数据量、格式复杂度与团队维护成本，多数业务系统使用EasyExcel即可满足，遇到复杂报表时POI加精心设计的内存管理依然能胜任，关键是把数据从内存中解放出来,让流向始终可控。
Java Web导出Excel常见问题解答
如何在服务端控制导出权限？
访问控制应在业务层拦截，在Controller前通过Spring Security或拦截器校验角色权限，导出接口和普通查询接口权限一致，不要把SQL暴露，更安全的做法是把导出操作记录到操作日志,便于追溯。
导出的Excel样式太多该如何优化？
大量自定义样式的单元格会显著增加文件大小和生成时间，建议做法：预先设计一个模板文件（含表头、字体、颜色、列宽），每次填充数据时直接使用模板，EasyExcel支持ExcelWriter和FillConfig配合模板写入，性能和样式均可兼顾,POI也可以通过读取模板再进行填充。
导出时如何保持日期格式正确？
EasyExcel中，@DateTimeFormat("yyyy-MM-dd HH:mm:ss")注解可控制字段的Excel单元格格式，POI中需要手动创建CellStyle并设置数据格式字符串，注意默认日期序列化可能会显示为数字，必须显式指定格式，这是排查乱码之外最常见的格式问题,确保实体注解或POI数据格式都正确即可。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/495696.html
