com.alibaba:easyexcel这条依赖，我估计不少 Java 项目里现在还躺着。

能跑，也没人敢随便动。

但这两年它的剧情确实有点连续剧的意思：EasyExcel 进入维护模式，后来冒出来一个 FastExcel，刚把包名从 com.alibaba.excel 换成 cn.idev.excel，现在 FastExcel 又没了。

这次新名字叫 **Apache Fesod (Incubating)**。

看到这里我第一反应也是：又改？

不过这次和之前不太一样，它不是作者闲着没事重新起了个名字，而是项目已经进入 Apache 软件基金会孵化器。2025 年 9 月 Fesod 通过 Apache Incubator 投票，随后仓库迁入 Apache；目前官方最新稳定版本已经是 2.0.2-incubating。

先把这几年的关系捋一下。

EasyExcel 并没有突然“不能用了”。

阿里官方仓库给出的说法比较克制：逐步进入维护模式，继续保证基本功能和 Bug 修复，但不再主动新增功能。

这句话做业务的人一看就明白。

老项目继续跑问题不大，但你要是今天新建一个服务，还指望它后面不断适配新需求、新版本，我就不会那么放心了。

FastExcel 后来接上了这条线。

到了 2025 年，FastExcel 又进入 Apache，项目名最终变成了 Fesod。官方现在对这段关系写得也很直接：FastExcel 已经捐赠给 Apache 软件基金会，并以 Apache Fesod 的名字继续孵化。

所以别把它理解成三个完全不同的 Excel 框架。

更像是：

EasyExcel
    ↓
FastExcel
    ↓
Apache Fesod (Incubating)

真正让我觉得这次值得换的，不是名字前面多了个 Apache。

而是项目的维护方式变了。

以前这种开源项目我最怕什么？

不是 API 不好用，是核心作者哪天工作一忙，Issue 一年没人回，PR 堆几十个。你业务里又已经用了几十处，想换都不好换。

进 Apache 之后也不能保证项目“永远不死”，这个话谁说都不靠谱。但至少代码仓库、版本发布、Committer、邮件列表和社区治理，不再只压在某一个作者身上。

这对基础组件比多几个 API 重要。

而且这次迁移没有想象中那么疼。

FastExcel 1.3.0 原来是：

<dependency>
<groupId>cn.idev.excel</groupId>
<artifactId>fastexcel</artifactId>
<version>1.3.0</version>
</dependency>

现在换成：

<dependency>
<groupId>org.apache.fesod</groupId>
<artifactId>fesod-sheet</artifactId>
<version>2.0.2-incubating</version>
</dependency>

包路径也跟着进了 Apache：

cn.idev.excel.*

变成：

org.apache.fesod.sheet.*

这里有个地方我会直接改，不会为了“少改代码”继续留兼容入口。

FastExcel 和 FastExcelFactory 在 Fesod 里暂时还能编译，但已经被标记为废弃，官方推荐的新入口是 FesodSheet。既然都升级依赖了，就别给下一次迁移继续埋雷。

比如一个实际点的对账单导入，我一般不会把 Excel 一次性读成一个大 List，再往数据库塞。

写成按行缓存、分批落库更稳：

publicfinalclassBillImportListenerimplementsReadListener<BillRow> {

privatestaticfinalint FLUSH_SIZE = 200;

privatefinal List<BillRow> pending = new ArrayList<>(FLUSH_SIZE);
privatefinal BillRepository billRepository;

publicBillImportListener(BillRepository billRepository){
this.billRepository = billRepository;
    }

@Override
publicvoidinvoke(BillRow row, AnalysisContext context){
if (row.getBillNo() == null || row.getAmount() == null) {
return;
        }

        pending.add(row);

if (pending.size() >= FLUSH_SIZE) {
            flush();
        }
    }

@Override
publicvoiddoAfterAllAnalysed(AnalysisContext context){
        flush();
    }

privatevoidflush(){
if (pending.isEmpty()) {
return;
        }

        billRepository.saveBatch(List.copyOf(pending));
        pending.clear();
    }
}

调用入口现在就是：

publicvoidimportBill(Path excelFile, BillRepository repository){

    BillImportListener listener = new BillImportListener(repository);

    FesodSheet.read(
            excelFile.toFile(),
            BillRow.class,
listener
        )
        .sheet("对账明细")
        .doRead();
}

这个写法我更喜欢。

Listener 每次导入重新创建，状态不会串；200 条刷一次数据库，也不会傻乎乎把十几万行全压在 JVM 里。Fesod 现在仍然保留了这种监听器、流式读取的使用方式，所以从 FastExcel 过去，业务逻辑基本不需要推倒重写。

那 EasyExcel 老项目到底要不要马上换？

我不会看到“进入维护模式”四个字，第二天就拉个分支全项目替换。

线上跑了几年、Excel 功能也已经稳定的系统，贸然升级基础库，收益未必覆盖回归成本。

但新项目，我会直接看 Fesod。

已经用了 FastExcel 的项目，我反而建议尽早迁。因为这条迁移路径现在已经非常清楚：依赖换掉、package 换掉、FastExcel 入口改成 FesodSheet，然后把导入导出、日期格式、合并单元格、自定义转换器这些地方重点回归一遍。

别只测一个“hello.xlsx”就上线。

还有一点别看漏了：名字后面现在仍然带着 Incubating。

这意味着 Fesod 已经进入 Apache，但还处于孵化阶段，并不是已经毕业的 Apache 顶级项目。Apache 官方自己也专门强调过，孵化状态不代表代码一定不稳定，但说明项目治理还在接受进一步检验。

所以“再不会跑了”可以当标题看。

真做技术选型，我更愿意换个说法：

EasyExcel 这条 Java Excel 工具链，绕了一圈之后，终于从“某个公司维护”“某个作者继续维护”，走到了社区治理这一步。

名字大概率还得适应几天。

至少这次改 pom.xml，我没那么嫌麻烦了。