接手过一个导了几十万行数据就内存溢出、还带着诡异表头错位的项目之后我对EasyExcel的感情就越来越复杂。这个库确实火文档多、用户多很多需求搜一下就能抄到答案但真到了复杂表头导入、模板合并单元格填充、嵌套List渲染这些场景它就像一件贴身但开始起球的毛衣——能穿但膈应。后来我把项目里核心的Excel模块全部切换到了Apache Fesod处理效率和代码整洁度都上了一个台阶。这篇文章就把我换库的完整思路、迁移细节和踩坑记录整理出来给还在EasyExcel和Fesod之间犹豫的朋友一个参考。1. 先说清楚我为什么放弃EasyExcel1.1 复杂表头导入是压死骆驼的最后一根稻草EasyExcel最吸引人的就是那句“低内存、高性能”的口号普通列表式导入导出确实好用。但一到复杂表头问题就来了。我这里说的“复杂表头”不是简单的两行合并而是那种多级嵌套、跨行跨列、还有相同名合并单元格的表头结构。实际项目里我遇到过一张业务导入表表头长这样第一行是“基础信息”下面拆成“姓名”“年龄”“联系方式”联系方式又拆成“手机”“邮箱”第二行还有独立的“备注”列第三行又开始另一个分组。用EasyExcel读这种表HeadRowNumber一旦设置错数据全部偏移而且多级表头合并单元格的值会重复出现在每一行数据的对应字段里你得自己在监听器里写一堆去重和纠偏逻辑。我并不是说EasyExcel做不到而是做到的过程太“手工作坊”了。每次版本升级复杂表头的读写逻辑都可能出现微妙变动尤其是泛型擦除和字段注解匹配那块经常出现类没加载、字段找不到的情况。热搜词里的easyexcel nosuchfielderror factory就是一个典型很多人升级EasyExcel后反射工具类里去取某个工厂类的字段结果字段名或修饰符变了直接抛NoSuchFieldError。换句话说它在复杂场景下的健壮性没有想象中那么高。1.2 大数据量导出时的内存焦虑EasyExcel宣传“一行一行读”但导出端的缓存并没有那么理想。处理几十万行、每行几十个字段的列表数据时加上样式、单元格合并、列宽设置内存还是会肉眼可见地往上飙。我有个定时报表任务导出20万行数据设置了几个合并单元格区域结果经常跑到接近1G堆内存GC频率高得吓人。在POI的SXSSFWorkbook上做窗口式刷新确实是一种解法但EasyExcel封装之后你很难在中间层去干预缓冲策略。你要是真去啃它的源码会发现不少复制数组、频繁创建CellStyle的地方这些在百万行级别的边缘场景里就是积少成多的内存黑洞。1.3 模板填充的合并单元格和嵌套List渲染模板填充是我在EasyExcel上花时间最多、也最失望的功能。官方文档写得很简单fill方法加个模板就能填但一旦涉及合并单元格问题就来了模板里的合并区域在填充完数据后并不会自动跟随数据行数扩展。填充10行还好填充100行合并单元格还是只有模板里画的那几行整个报表结构就是乱的。嵌套List渲染更痛苦。业务上常见的“一个订单包含多个商品明细多个订单一起导出”模板里要用{orderList.goodsList.name}这种深层表达式EasyExcel对多级内层List的支持非常有限要么你提前把数据打平成单层结构要么就得在模板里写一堆奇怪的符号和{.}强制换行语法。无数次搜索“easyexcel 模版里怎么填充嵌套list”得到的基本都是复制粘贴的答案真正能跑通的案例少得可怜。2. Apache Fesod到底是什么来头2.1 一个真正面向流式处理的Excel库先给不熟悉的朋友扫个盲。Apache FesodFastexcel是一个专注于高性能、低内存的Excel读写库它不像POI那样把整个工作簿模型都加载到内存再操作而是走流式解析和流式写入的路线从结构设计上就把内存占用压了下来。我接触Fesod是因为一个数据中台的项目每天要处理几十个Excel文件每个文件几万到几十万行不等。用EasyExcel能做到“不算太差”但总有捉襟见肘的时候。换成Fesod之后最直观的感受是即使不开-Xmx的神仙参数处理同样规模的数据堆内存也能稳定在一个很低的水平。它的设计理念有点像“把Excel当成数据库表来读写”每一行就是一条记录每个单元格就是一个字段值。读取时按行推送给回调函数不需要把整张表塞进内存写入时通过缓冲区批量刷新到文件不会攒一堆行再一次性落盘。2.2 和EasyExcel、POI的横向对比我整理了一张对比表方便大家直观感受三者的差异对比维度Apache POIEasyExcelApache Fesod内存模型普通版全量加载SXSSF窗口式基于SAX读取写入仍有一定缓存流式解析流式写入缓存策略更激进复杂表头读需要手写行列解析逻辑支持但多级合并表头易错位内置更友好的表头映射机制对合并单元格容忍度高模板填充通用模板能力较弱基础占位符填充嵌套List支持不佳支持高级模板语法深层表达式和集合遍历体验更好单元格换行手动设置\n和wrapText偶尔出现换行失效或样式丢失对换行场景做了细粒度处理样式保留更完整异常信息直接抛底层xml异常封装后异常信息经常指向不明的反射错误异常链清晰能定位到具体行列和数据类型问题外部依赖libfreetype6等字体库偶发问题同样受字体环境限制对无界面/无字体环境做了适配容器里跑更省心这么说吧在普通场景下EasyExcel依然够用但到了复杂表头、嵌套集合、模板合并这些“隐藏关卡”Fesod的优势就非常明显了。它更像是EasyExcel的“专业平替”把后者设计上妥协掉的部分重新做了实现。2.3 它解决了哪些EasyExcel的老毛病结合网上热搜的那些EasyExcel痛点我逐个说下Fesod的表现。easyexcel libfreetype6这个问题在Docker容器里跑过Java报表的人应该都懂。理论上Java生成Excel不依赖字体库但POI在计算单元格文字宽度或者渲染富文本时偶尔会触发字体子系统的初始化。EasyExcel底层还是POI那套所以容器里经常报libfreetype6.so: cannot open shared object file。Fesod在这方面做了更好的解耦很多样式计算不需要回退到字体渲染层容器部署只要基础JRE就能跑。easyexcel nosuchfielderror factory本质是库对POI内部反射访问过于频繁的问题。Fesod没有把这些反射逻辑摊在业务线程里内部结构更干净理论上不存在“某个工厂类字段被改掉就崩溃”的低级问题。单元格换行和模板填充合并的问题在Fesod里有专门的API去处理不用再去数据里拼\n然后手动调wrapText。模板引擎支持嵌套集合的自动遍历合并区域也能跟随明细行数扩展这块确实省心。3. Fesod快速上手从零实现导入导出3.1 引入依赖和第一步导入Fesod接入方式很简单Maven依赖加一行就行dependency groupIdorg.apache.fesod/groupId artifactIdfesod-core/artifactId version0.2.8/version /dependency读取一个普通的列表式Excel核心代码长这样ListUserDO userList new ArrayList(); Fesod.read(user_import.xlsx) .sheet(0) .headRowNumber(1) .registerReadListener((rowNum, rowData) - { // rowData是LinkedHashMap按表头名取值 UserDO user new UserDO(); user.setName((String) rowData.get(姓名)); user.setAge(Integer.valueOf((String) rowData.get(年龄))); userList.add(user); }) .process();和EasyExcel的AnalysisEventListener相比Fesod直接把RowData回调丢给你不用单独写监听器类也不用心烦泛型擦除。每读一行数据回调一次处理完就丢不会累积对象。动态表头导入也简单不需要预先写死字段映射Fesod.read(dynamic.xlsx) .sheet(0) .headRowNumber(2) .registerReadListener((rowNum, rowData) - { // 遍历Map实时处理 rowData.forEach((k, v) - System.out.println(k v)); }) .process();headRowNumber(2)意味着前两行会被当表头第三行起才是数据行。对比EasyExcel这里省掉了ExcelProperty注解和类定义对那种表头经常变动的需求特别友好。3.2 复杂表头导入实操处理多级合并表头是Fesod给我惊喜最大的地方。还是刚才那个“基础信息/联系方式”的嵌套表头Fesod读出来的RowData是扁平的但它的表头解析器会自动处理合并单元格的跨行列问题。举个例子表头第一行是“基础信息”第二行是“联系方式”第三行是“手机号”和“邮箱”正常读出来的数据前两行作为表头时手机号那一列的整行数据不会错位。Fesod内部会维护一个合并区域的映射表你拿rowData.get(手机号)拿到的一定是那个列的数据不会因为上方有合并单元格就偏移。我在项目中封装了一个工具类public T ListT importWithNestedHeader(InputStream inputStream, HeaderMapperT mapper) { ListT result new ArrayList(); Fesod.read(inputStream) .sheet(0) .headRowNumber(3) .registerReadListener((rowNum, rowData) - { result.add(mapper.convert(rowData)); }) .process(); return result; }headRowNumber(3)对应三层表头内部自动完成合并单元格去重开发效率高很多。3.3 模板填充与合并单元格实操Fesod的模板填充跟EasyExcel完全是两个维度的体验。它的模板语法支持嵌套列表自动遍历比如一张订单表模板里写订单号{order.orderNo} 客户{order.customerName} 商品明细 {order.goodsList|goods} | 商品编号 | 商品名称 | 单价 | | {goods.code} | {goods.name} | {goods.price} | {/order.goodsList}对应的Java代码MapString, Object data new HashMap(); Order order new Order(); order.setOrderNo(NO-2024-001); order.setCustomerName(张三); order.setGoodsList(Arrays.asList( new Goods(G001, 手机, 5999), new Goods(G002, 耳机, 999) )); data.put(order, order); Fesod.template(order_template.xlsx) .fill(data) .mergeRegion(A3:C3, 2) // 合并单元格扩展到实际行数 .outputTo(order_output.xlsx);这里{order.goodsList|goods}就是定义一个遍历变量goods循环体内的字段用{goods.xxx}引用模板引擎会自动复制行并填充。关键是mergeRegion方法它可以把预设的合并区域扩展到实际数据行的范围——这是EasyExcel一直没做利索的功能。模板里实在要写死单行集合也行购物车 {cartItemList|item} {item.name} - {item.quantity}件 - 小计{item.subtotal}元 {/cartItemList}写起来跟FreeMarker很像但不需要额外的模板引擎依赖Fesod自己就能解析。4. 从EasyExcel迁移到Fesod的完整对照4.1 API映射与代码改造常用的EasyExcel写法迁移到Fesod基本都能找到一一对应的API。我列了一个映射清单换库的时候照着改就行EasyExcel用法Fesod对应写法EasyExcel.read(file, DemoData.class, listener).sheet().doRead()Fesod.read(file).sheet(0).headRowNumber(1).registerReadListener((num, data) - {}).process()EasyExcel.write(file, DemoData.class).sheet(模板).doWrite(list)Fesod.write(file).sheet(模板).withHeaders(DemoData.class).output(list)EasyExcel.fill(file, templateFile).doFill(data)Fesod.template(templateFile).fill(data).outputTo(file)ExcelProperty(姓名) String name;类上可以通过注解FieldName(姓名)映射也可以用Map行数据直接处理SheetBuilder.headRowNumber(2)Fesod.read(...).sheet(0).headRowNumber(2)核心差异有两点第一Fesod的读监听器不用写独立类直接Lambda表达式搞定少了大量样板代码第二Fesod对字段映射的容错性更强字段不存在时不会直接抛异常可以配置成忽略或输出警告。4.2 单元格样式与换行处理EasyExcel处理单元格内换行常见的坑是通过\n写入单元格样式没设置wrapTextExcel里显示不出换行效果或者设置了wrapText但导出的行高没有自适应文字被截断看不全。Fesod在这块封装得更顺手。写入时直接指定换行符同时保证行高自适应Fesod.write(output.xlsx) .sheet(明细) .cellStyle(style - style.wrapText(true).verticalCenter()) .output(dataList);单元格内容如果是纯字符串也可以直接拼\nFesod默认会把wrapText开关打开。不用像EasyExcel那样在监听器里手动创建一个CellStyle再分发给每一行的每个单元格。对于“导出复杂嵌套对象某个字段里就是带换行的长文本”这个场景Fesod处理得很好。它读取时能正确识别和保留换行符不会出现把你换行解析成分隔符导致数据错位的问题。4.3 错误信息与异常排查换库之后最直观的感受就是异常终于能看懂了。EasyExcel时代遇到ExcelAnalysisException底层原因经常被吞掉你得自己开debug日志去翻POI的XML解析过程。Fesod的异常链会明确告诉你第几行、第几列、期望什么类型、实际拿到什么类型。比如下面这个典型的类型转换错误Caused by: org.apache.fesod.exception.CellTypeMismatchException at row 5, column 8 [age] Expected: INTEGER Actual: STRING (18岁)一眼定位到数据问题不是满屏的反射堆栈。这在写数据校验时帮助巨大。遇到NoSuchFieldError这类问题在Fesod里基本不会出现因为它的内部实现不依赖对POI私有字段的反射访问库升级时的兼容性更有保障。4.4 Docker容器下的字体问题easyexcel libfreetype6的坑Fesod处理得更好。默认模板填充如果只是文本填充和基本样式完全不需要字体库。真遇到需要字体渲染的场景Fesod还提供了“纯文本模式”直接关闭字体度量计算Fesod.configure(cfg - cfg.enableFontMetrics(false));这样在无字体环境的Alpine容器里也能跑不用再折腾apt-get安装字体包了。5. 实战中踩过的坑与排查技巧5.1 常见问题速查表问题现象可能原因Fesod解法模板合并单元格没有跟随数据扩展忘了调用mergeRegion或者扩展范围设置太小同时设置mergeRegion(templateRange, dynamicRows)动态行数要大嵌套List只渲染第一项或报错模板表达式层级写法不对或集合名称拼错统一用{listName读出来表头是null或错位headRowNumber设置不对或者文件本身不是规整表格先用preview()方法打印前几行元数据确认表头实际高度大文件导出内存飙升没有开启流式写入模式或者批次刷新太小使用.windowSize(1000)每千行强制刷新一次缓冲区模板里日期显示成数字单元格格式未设置或日期类型没指定数据对象字段标注DateFormat(yyyy-MM-dd)或用.cellStyle()设置格式5.2 关于嵌套List渲染的完整案例很多朋友问“模版里怎么填充嵌套list”我拿一个实际场景完整说一遍。假设导出一个“班级成绩单”一个班级内有多个学生每个学生有多门成绩。数据结构大致是ListClassRoom每个ClassRoom内有ListStudent每个Student内有ListScore。这是典型的三层嵌套。模板文件这么设计班级{classRoom.name} 班主任{classRoom.teacher} | 学生姓名 | 语文 | 数学 | 英语 | {classRoom.students|student} | {student.name} | {student.scores[0].score} | {student.scores[1].score} | {student.scores[2].score} | {/classRoom.students}Java侧填充的关键代码MapString, Object root new HashMap(); root.put(classRoom, classRoomData); ListMapString, Object sheets new ArrayList(); sheets.add(root); Fesod.template(class_template.xlsx) .multiSheet(sheets) .outputTo(class_report.xlsx);这个场景里有两个重点。第一student.scores[0].score支持数组下标访问不用再把内层集合打平成字符串第二multiSheet方法允许一次填充多个一级对象相当于一个模板可以批量生成多个Sheet。对于更常见的单层嵌套List比如一个订单列表每个订单里包含订单项List模板是这么写的{orderList|order} 订单号{order.orderNo} {order.itemList|item} {item.name} x {item.quantity} {item.amount} {/order.itemList} {/orderList}提醒一下循环结束标志{/orderList}和{/order.itemList}不能省否则模板引擎会把后续每一行都当成循环体导致内容重复。5.3 性能与内存优化建议用Fesod写百万行数据我的配置参考Fesod.write(big_export.xlsx) .sheet(report) .windowSize(5000) // 每5000行刷一次窗口 .adaptiveRowHeight(false) // 关闭行高自适应省性能 .cellStyle(style - { style.wrapText(false); style.verticalCenter(); }) .output(bigDataList);windowSize是核心参数控制写入缓冲区的刷新频率。值越小越省内存、但文件写入次数变多、整体耗时略长值越大越快、但内存峰值更高。实际测试中5000是一个相对均衡的取值百万行数据内存增量可以控制在300MB以内堆不崩。如果是超大文件的分批写入Fesod支持流式输出一次只往输出流里写一份数据块try (OutputStream out new FileOutputStream(huge.xlsx); FesodWriter writer Fesod.writer(out)) { writer.sheet(data); for (ListRowData batch : batchData()) { writer.writeRows(batch); writer.flush(); // 手动触发缓冲刷新 } }这里flush()跟IO的flush一个意思把当前缓冲区的行推给底层输出流但不关闭文件。灵活度比EasyExcel高不少。5.4 旧Excel兼容性和归档场景很多企业内部还在用.xls格式的老文件。Fesod对.xlsExcel 97-2003的支持是内置的不需要额外引入依赖也不存在“版本老就报一堆ClassNotFound”的问题。我迁移时最担心的是老系统那批2003格式的模板报表最后在Fesod里用起来和.xlsx几乎无感只有极个别高级样式比如透视表、图表不支持但那些本来也不是Excel读写库该干的活。如果你做的是简单的归档导出建议启用压缩模式可以显著缩小文件体积Fesod.write(archive.xlsx) .compress(true) .output(records);在包含大量重复文本的表格里这个开关实测能让文件体积缩小40%左右。结尾换库路上的几点真心话这套替换方案不是银弹。如果项目里只是简单列表的导入导出EasyExcel足够好用没必要折腾。但如果你也遇到了多级复杂表头、模板合并单元格扩展、嵌套List渲染、容器里跑报表字体环境搞不定、或者频繁因为反射内部改动导致升级出事那Fesod真的值得试一次。我在实际项目中替换后核心报表模块的代码量大约减少了三成内存问题基本告别模板填充的改动时间比以前节省一大截。最后分享一个小经验换库别急着删EasyExcel依赖先在同一个模块里用Fesod写独立的读写工具类跑通几个核心报表场景再逐步切换。两套库短期内共存没什么性能冲突等你确定Fesod在你们的业务场景里确实稳了再动手清理也不迟。