ARTICLE · 1023788

还在用 EasyExcel 的注意了:它已停止维护

发布时间：2026-09-17 07:25:01 最近访问：2026-09-17 07:25:01

上周有位老哥在后台私信我：“公司项目还躺在 EasyExcel 4.0.3 上，这玩意还能用吗？”

我回他一句：能用，但建议你尽快安排迁移。

原因很简单：EasyExcel 的 GitHub 仓库早在 2025 年 9 月就被阿里正式归档了，变成只读状态。它不仅没有新功能，连 Bug 都没人修了。

但这个故事有个相当精彩的后续：EasyExcel 的原作者在离开阿里后重写了一个项目 FastExcel，而 FastExcel 最近又“毕业”进了 Apache 软件基金会，更名为 Apache Fesod (Incubating)。

今天这篇文章，就把这条“一年三连跳”的换代路线讲清楚，顺便给你一套可以直接抄的迁移方案。

一、EasyExcel 是怎么“凉”的

先简单回顾一下历史。EasyExcel 是阿里 2018 年开源的 Java Excel 处理库，巅峰时期在 GitHub 上累计拿下超过 33,000 颗 Star，是当年最火的 Java 项目之一。

它最大的贡献，是把 Excel 解析方式换成了 SAX 流式解析——不把整个文件一次性怼进内存，而是一行一行地读。官方数据是：16MB 内存就能读取 75M（46 万行 25 列）的 Excel，耗时 23 秒。在 POI 动不动就 OOM 的年代，这就是救星级别的存在。

但拐点出现在 2023 年：EasyExcel 的核心作者玉箫从阿里离职。之后项目进入了事实上的停更状态：

GitHub Issues 响应延迟超过 30 天；
PR 合并基本停滞；
近半年没有正式版本发布（最后一个 v3.3.2 停在 2023 年 10 月）；
对 Spring Boot 3.x、Java 21、Apache POI 5.x 的兼容支持持续滞后。

2024 年 11 月，阿里官宣 EasyExcel 进入维护模式；2025 年 9 月，仓库正式归档、只读。

一个 33k Star 的项目就这样画上了句号。但就在大家一筹莫展的时候，原作者站了出来。

二、FastExcel 接棒，然后“毕业”进了 Apache

1. FastExcel：不是 fork，是重构

2024 年 12 月，原作者公开了新项目 FastExcel。很多人以为是 EasyExcel 换个马甲，结果一看代码才发现这是一场彻底重构。它做了三件关键的事：

性能继续压榨
：在 SAX 解析基础上进一步优化内存与 IO，有开发者实测从 EasyExcel 切过去后，处理时间从近 1 分钟降到 18 秒左右，内存峰值控制在 800MB 以内；
补齐实用特性
：1.0.0 就支持读取指定行数、Excel 转 PDF 等原本要自己写一堆代码的功能；
兼容 EasyExcel API
：换包名和 Maven 依赖即可完成迁移，很多项目一行代码都不用改。

FastExcel 上线一个月，Star 就突破了 1.8K。

2. Fesod：不是“又凉了”，是“毕业”了

如果你最近去 GitHub 搜 FastExcel，可能会发现原项目搜不到了——别慌，它不是死了，而是被整套捐给了 Apache 软件基金会，成为 Apache POI 的子项目，更名为 Apache Fesod (Incubating)。Fesod 的全称是 Fast. Easy. Spreadsheet and Other Documents。

2026 年 1 月 21 日，Fesod 发布了第一个孵化版本 2.0.0-incubating；2 月 11 日，2.0.1-incubating 紧随其后。

这意味着代码所有权从个人/公司转给了 Apache 基金会——和 POI、Maven、Tomcat 一个待遇。长期维护有了保障，不会再出现“核心作者一离职就停更”的剧本。

对比维度	EasyExcel（停更）	FastExcel（过渡）	Apache Fesod（孵化中）
API 兼容性	—	与 EasyExcel 完全一致	与 FastExcel 基本一致
迁移成本	—	换包名即可	换坐标 + 改 import + 换入口类
维护状态	❌ 已归档只读	⚠️ 过渡命名，新项目别用	✅ Apache 基金会保障
最新版本	v4.0.3	1.3.0	2.0.1-incubating
开源协议	Apache 2.0	MIT（商业友好）	Apache 2.0

三、迁移三步走：从 FastExcel / EasyExcel 到 Fesod

先回答一个高频问题：上个月刚改完 import，怎么又换名字了？

别紧张，这次不是停更，是升级。判断标准很简单：新项目直接上 Apache Fesod，少一次后续迁移；老项目按下面三步走。

第一步：替换 Maven 依赖

XMLpom.xml

<groupId>com.alibaba</groupId>

<artifactId>easyexcel</artifactId>

</dependency>

<groupId>cn.idev.excel</groupId>

<artifactId>fastexcel</artifactId>

</dependency>

<groupId>org.apache.fesod</groupId>

<artifactId>fesod</artifactId>

<version>2.0.1-incubating</version>

</dependency>

第二步：修改导入包

把 cn.idev.excel（EasyExcel 用户则是 com.alibaba.excel）统一改成 org.apache.fesod：

JavaImportRefactor.java

// 旧：EasyExcel / FastExcel 的导入

importcom.alibaba.excel.EasyExcel;

importcn.idev.excel.FastExcel;

importcn.idev.excel.annotation.ExcelProperty;

// 新：Apache Fesod 的导入

importorg.apache.fesod.Fesod;

importorg.apache.fesod.annotation.ExcelProperty;

第三步：换入口类

入口类从 EasyExcel / FastExcel 换成 Fesod，链式 API 几乎一模一样：

JavaEntryClass.java

// 旧写法（FastExcel）

FastExcel.write(response.getOutputStream(), User.class)

.sheet("用户列表")

.doWrite(users);

// 新写法（Fesod，API 几乎一致）

Fesod.write(response.getOutputStream(), User.class)

.sheet("用户列表")

.doWrite(users);

IDEA 里用 Replace in Files（Ctrl+Shift+R）全局替换包名，两分钟就能搞定一个中型项目。唯一要留心的是 2.x 相比 1.x 有少量 API 微调，编译报红的地方逐个确认即可。

四、实战：百万行订单导出不 OOM

迁移完了，来点真家伙。下面是我按 Fesod 的写法重构的一个分页流式导出接口，边查库边写 Excel，百万行数据内存也不炸：

JavaExportController.java

@RestController

@RequestMapping("/api/export")

publicclassExportController {

@Resource

privateOrderServiceorderService;

@GetMapping("/orders")

publicvoidexportOrders(HttpServletResponseresponse) throwsIOException {

// 1. 设置响应头

response.setContentType(

"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet");

response.setCharacterEncoding("utf-8");

StringfileName = URLEncoder.encode("订单报表", "UTF-8").replaceAll("\\+", "%20");

response.setHeader("Content-disposition",

"attachment;filename*=utf-8''" + fileName + ".xlsx");

// 2. 流式写入：每次查一页、写一页，不堆积在内存

try (ExcelWriterwriter = Fesod.write(response.getOutputStream(), OrderExportVO.class)

.sheet("订单数据")

.build()) {

intpage = 1;

intpageSize = 10000;

while (true) {

List<OrderExportVO> pageData = orderService.pageOrders(page, pageSize);

if (pageData.isEmpty()) {

break;

}

writer.write(pageData);

page++;

}

对应的导出实体类，用 @ExcelProperty 标注列名即可：

JavaOrderExportVO.java

@Data

publicclassOrderExportVO {

@ExcelProperty("订单号")

privateStringorderNo;

@ExcelProperty("下单时间")

privateDatecreateTime;

@ExcelProperty("金额（元）")

privateBigDecimalamount;

@ExcelProperty("状态")

privateStringstatus;

}

跑起来之后，观察一下 GC 情况：

LOGexport.log

[Fesod-Export] rows=500000, cost=21s, fullGC=0, heapPeak=612MB

[Fesod-Export] rows=1000000, cost=43s, fullGC=1, heapPeak=708MB

[Fesod-Export] export finished, file=order-report-202609.xlsx (38.2MB)

百万行导出，内存峰值稳稳控制在 1GB 以内，这就是流式写入的底气——有物流企业切换到这套方案后，报表生成时间从 4 小时缩短到 20 分钟，服务器资源占用减少 60%。

五、6 种 Excel 方案怎么选

方案	维护状态	适用规模	内存模型	致命短板
Apache POI	活跃	任意	DOM（重）	十万行级写入容易 OOM
POI SXSSF	活跃	大文件	流式	写还行，读不擅长
HuTool Excel	活跃	< 1 万行	简单封装	高级特性受限
EasyExcel	❌ 已停更	任意	流式	不再有新功能 / Bug 修复
FastExcel	⚠️ 过渡命名	任意	流式	已是过渡命名
Apache Fesod	✅ Apache 孵化	任意	流式	仍在 Incubating 阶段

再看一组 50 万行写入的性能实测数据：

方案	写入速度	GC 次数	GC 暂停	综合评价
dhatim/FastExcel	13s	18 次	285ms	速度最快，内存效率差
Apache Fesod	21s	7 次	68ms	综合最优
EasyExcel / FastExcel	相当	相当	42-55ms	性能一致

Fesod 的写入速度和其他流式框架在同一量级（差异不到 10%），但内存效率遥遥领先——GC 次数只有其他框架的 40% 左右。高并发场景下，一次长 GC 暂停就可能抵消所有速度优势，所以综合来看 Fesod 更值得押注。

六、优缺点，不吹不黑

优点

API 无缝迁移
：从 EasyExcel 到 FastExcel 再到 Fesod，API 几乎一致，迁移成本极低；
流式处理，百万行不 OOM
：继承 SAX 流式解析基因，内存占用始终在 MB 级；
功能持续迭代
：读取指定行数、Excel 转 PDF 等实用能力不断补齐；
Apache 基金会保障
：代码所有权转给基金会，长期维护有靠山；
协议商业友好
：MIT / Apache 2.0，商业场景免费使用、可二开；
内存效率领先
：GC 次数约为其他流式框架的 40%。

缺点

还在孵化阶段
：2.x API 相比 1.x 有少量微调，随时可能变动；
命名变迁有点乱
：一年三连跳，很多人刚改完 FastExcel 又得改 Fesod；
FastExcel 已不再更新
：1.3.0 之后不会再有新功能和 Bug 修复；
迁移仍需改代码
：换坐标、改 import、换入口类，工作量不大但不是零。

七、选型建议

你的场景	推荐	理由
新项目	✅ Apache Fesod	少一次后续迁移
在用 EasyExcel	✅ 迁到 Fesod	换依赖 + 改 import
在用 FastExcel	✅ 迁到 Fesod	换坐标 + 改 import + 换入口类
极简场景（几行数据）	HuTool 一行调用	别上重武器
需要 Excel 转 PDF	✅ Fesod	内置该能力

最后回到开头的问题：EasyExcel 凉了吗？凉了，2025 年 9 月仓库归档，不再有任何维护。FastExcel 死了吗？没有，它只是“毕业”了——从个人项目升级成了 Apache 基金会的孵化项目。

对开发者来说，行动清单其实就两条：新项目直接上 Apache Fesod；老项目排期迁移，从 EasyExcel / FastExcel 切到 Fesod。别因为“又要改代码”就犹豫，这次换来的是 Apache 级的长期维护保障。

选开源库，就是在选一个未来三年还活着的靠山——不要只看它现在有多火，要看它背后是谁在兜底。

·················END·················

如果觉得这篇对你有帮助，点个“在看”，加个“星标”，下次推送就不会迷路啦。你的支持，就是我持续输出的最大动力，谢谢！😀

一、EasyExcel 是怎么“凉”的

二、FastExcel 接棒，然后“毕业”进了 Apache

1. FastExcel：不是 fork，是重构

2. Fesod：不是“又凉了”，是“毕业”了

三、迁移三步走：从 FastExcel / EasyExcel 到 Fesod

第一步：替换 Maven 依赖

第二步：修改导入包

第三步：换入口类

四、实战：百万行订单导出不 OOM

五、6 种 Excel 方案怎么选

六、优缺点，不吹不黑

优点

缺点

七、选型建议

相关学习资料