EasyExcel 還能用嗎？阿里開源 Excel 庫的現況與搬家路線

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

寫過 Java 後端的人，pom 裡多半出現過 com.alibaba:easyexcel 這一行。這個庫有超過 3.3 萬顆星，存在的理由很單純：Apache POI 讀大檔會把記憶體吃爆，而 EasyExcel 用串流重寫了這段解析，讓幾十萬列的試算表不再把服務推下懸崖。但它的 GitHub 倉庫已經在 2025 年 9 月被掛上唯讀封條，最後一個版本 4.0.3 停在 2024 年 9 月。同一段血統沒有死掉：它先以 FastExcel 之名另起爐灶，然後整個捐進 Apache 孵化器、更名 Fesod，並且在 2026 年 10 月 7 日這一天剛剛發布 2.1.0 版。

先把判斷放在前面：如果這個庫只跑在你公司內部、處理的都是自己系統產出的檔案，短期留在 4.0.3 站得住腳；但如果你的服務會吃外部來源的 Excel，或把使用者提供的網址交給圖片欄位處理，搬遷就該排進工程票了。

一紙溫和的維護公告，和一面黃色橫幅

EasyExcel 的停工方式相當客氣。倉庫 README 最頂端掛著一篇以簡體寫成的維護公告，大意是：感謝使用者長期支持，近期市場上出現更多優秀的資料處理工具，EasyExcel 將逐步進入維護模式，基本功能保持穩定、會持續修 bug，但不再主動新增功能，並建議使用者預留時間評估遷移。沒有指名接班人是誰，語氣像退休感言多過像棄坑宣言。

幾個可以釘死的時間點把話講得更白：最後一個 release 是 2024 年 9 月 11 日的 4.0.3，這也是 Maven Central 上至今的最新版；倉庫最後一次程式推進停在 2024 年 10 月 29 日；2025 年 9 月 4 日，GitHub 在頁面頂端掛出那面黃色橫幅「This repository was archived by the owner on Sep 4, 2025. It is now read-only.」。封存之後，倉庫連開新 issue 的入口都關了，累積到那天的 568 個未解 issue 與合併請求就此凍結，不會再有人回。

Pin

但公告和現實有一段落差，而且落差比字面上更難看。對照 commit 歷史，2024 年 10 月 29 日那筆把維護公告加進 README 的提交，就是這個倉庫的最後一次變更；換句話說，「會做 bug 修復」的承諾幾乎是掛上公告的當天就跳票，之後十個月零提交，2025 年 9 月直接封存。封存（archived）在 GitHub 的定義是整個倉庫唯讀，連維護者自己都推不了 commit，所以「維護模式」實際上是「維護終止」。這不是苛責，開源作者當然有退休的自由，而是提醒讀者：你如果還在等某個 issue 被修，那個等待已經有確定的答案了。

另一個容易被忽略的點：封存不等於下架。Maven Central 上的 com.alibaba:easyexcel:4.0.3 仍然可以正常解析下載，舊文件站 easyexcel.opensource.alibaba.com 也還開著，API 文件照常查得到。對既有專案來說一切如常，這正是危險的地方：依賴看起來活著，維護線其實已經斷了兩年。

它當年到底解決了什麼問題

如果你沒踩過 POI 的坑，它解釋了這個庫為何能長到三萬多顆星，也解釋了「留在這條血統」對某些團隊為何仍是合理選擇。

Excel 的 .xlsx 檔本質上是一包 ZIP，裡面裝著 XML。Apache POI 最常見的用法（UserModel）會把整份 XML 展開成記憶體裡的物件樹，你才讀完開頭幾列，整份檔案的中繼結構已經全部住進 heap；官方文件裡那組對照數字是：3M 的檔案用 POI 的 SAX 模式解析都還要約 100M 記憶體。EasyExcel 的作法是把 .xlsx 的解析整段重寫成事件流，讀到哪一列才把那一列交給你的 Listener，用完即丟；README 給的基準是 16M 記憶體、23 秒讀完 75M、46 萬列乘 25 欄的檔案。這些數字是專案方自己量測的宣稱，不是我的實測，但機制本身（串流事件模型取代全量載入）是十年來被大量 Java 服務驗證過的路數。至於更老的 .xls（BIFF 二進位格式），它沒有重寫，而是在 POI 原有的 SAX 模式上包了一層比較好用的模型轉換；換句話說，這個庫對新舊兩代檔案的投資深度本來就不對稱，2.1.0 把欄級讀取補到 XLS 與 CSV，算是延續了同一種補課邏輯。

附帶一提，README 還提到一種「極速模式」，速度更快但記憶體會回到 100M 出頭，等於用空間換時間。工程上沒有魔法，只有取捨，這個庫走紅靠的是把取捨往「省記憶體」那一端推到底。

血統搬了兩次家：從 FastExcel 收攏進 Apache

接下來這段遷徙史，官方在自己的部落格裡寫得很清楚。FastExcel 在 2024 年 10 月開源，由 EasyExcel 的原始核心維護者發起，Maven 座標換成 cn.idev.excel:fastexcel，一路出到 2025 年 8 月 22 日的 1.3.0，總共五個社群版本、二十多位貢獻者。用貢獻紀錄交叉驗證也對得上：EasyExcel 倉庫提交量最大的作者 zhuangjiaju（838 次提交，遙遙領先第二名），名字就列在 Fesod 的貢獻者名單裡。

這裡有個搜尋時的實際陷阱要提醒：Maven 中央倉庫上叫 fastexcel 的套件不止一個。org.dhatim:fastexcel 是另一個完全無關的 Java Excel 函式庫，一樣在寫試算表、一樣標榜大檔效能；你要找的 EasyExcel 後繼是 cn.idev.excel:fastexcel，看 groupId 才不會抱錯小孩。這種 artifact 撞名在 Java 生態不算罕見，但發生在「舊專案剛改名、大家急著搜尋」的時間點，殺傷力特別大。

第二次搬家把格局拉高了。2025 年 9 月 17 日，專案以 9 張約束票、零反對票通過 Apache 孵化器投票；9 月 25 日倉庫正式移交 Apache 軟體基金會，並更名為 Fesod，取自「fast easy spreadsheet and other documents」的縮寫。舊址 github.com/fast-excel/fastexcel 現在是個 301 轉址，直接指到 apache/fesod，你連釘選的書籤都不用改。

對不熟 Apache 治理的讀者，孵化器大概可以這樣理解：基金會的收容與考核機制，進來的專案要學會走 Apache 的郵件列表討論、投票、簽核發布流程，撐過一段觀察期才能畢業成正式頂級專案。換來的是商標與基礎設施保護，以及「這個專案不會因為某個人離職就蒸發」的制度保證。EasyExcel 的原班人馬選這條路，等於把「下一個維護者在哪」的問題交給制度回答；成敗則要看社群能不能長出超越任何單一作者的貢獻厚度，這點從 2.1.0 的跨國貢獻者名單看，方向是對的。

進了 Apache 之後的節奏也真的動了起來：

2.1.0 這版的份量值得單獨講：110 個 PR，來自中國、愛爾蘭、拉脫維亞、南韓的 10 位新貢獻者共同完成；功能上把欄級讀取延伸到舊版 XLS 與 CSV、新增凍結窗格的 @FreezePane 寫法、補上 LocalTime 轉換器，日期與數字的格式化器也加了快取，大檔讀取少做重複解析；工程面上導入了可重現建置（reproducible builds），把建置時間戳固定下來，讓任何人都能驗證「我從 Maven 抓到的 jar」和「從原始碼編出來的結果」一 byte 一 byte 相同，這在供應鏈攻擊時代是加分題；同一輪更新也把幾個依賴的已知問題（XXE 相關修補、fastjson2 與 slf4j 升級）一併清掉。對一個兩年前看起來要斷氣的專案來說，這份體檢報告算相當健康。

Pin

同一個抓圖元件，凍在 2024 的那一版沒有防護

講遷移建議之前，先看一個具體的對照，這比任何「專案活躍度」的抽象說法都更能回答「留在舊版到底損失了什麼」。

EasyExcel 有個元件叫 UrlImageConverter：當你的資料模型裡有 java.net.URL 型別的欄位，寫檔時它會在伺服器上直接開連線、把網址指到的圖抓回來嵌進儲存格。我把兩個版本從 Maven Central 抓下來解開對照：easyexcel-core-4.0.3.jar 裡這個 class 只有 2,688 bytes，對應的原始碼全文不到五十行，openConnection() 之前沒有任何檢查，唯一的安全措施是連線 1 秒、讀取 5 秒的逾時設定；fesod-sheet-2.1.0 的同一個 class 膨脹到 10,016 bytes，旁邊多出 9,254 bytes 的 UrlImageFetchPolicy 和它的 Builder。

新版政策層做的事，剛好就是舊版沒做的事：先驗網址再連線、只放行政策允許的通訊協定、遇到重導向時對新目標重新驗證並計算次數上限，而 2.1.0 起遠端圖片預設要走明確的允許清單。防護邏輯於是從「呼叫端自己小心」變成「庫本身預設拒絕」。

這個差距在 2026 年被正式命名了。當年 6 月，Fesod 官方發布安全通告 CVE-2026-49328（CVE 紀錄 6 月 1 日先行刊出，官方部落格 6 月 11 日刊出完整通告）：fesod-sheet 2.0.1 的 UrlImageConverter 對使用者供給的網址驗證不當，攻擊者可藉此讓伺服器對內網或受限位址發出請求，也就是 SSRF（伺服器端請求偽造）；修復版是 2.0.2，對應的修補 PR 在 5 月中合併，內容就是替圖片抓取加上 URL scheme 政策，從修復合併到正式通告相隔約四週。要精確地說：這個 CVE 的官方影響清單只列了 fesod-sheet 2.0.1，easyexcel 並不在名單上；但同一個零驗證的抓取器就躺在 easyexcel-core-4.0.3.jar 裡，而那個倉庫是唯讀的，這條修補線永遠不會回去。

Pin

攻擊場景用白話講一遍：你的服務提供「把資料匯出成 Excel」的功能，欄位裡的圖片網址來自使用者輸入；使用者把網址填成雲端平台的內部中繼資料位址，你的伺服器就乖乖替他跑一趟，把回應內容嵌進他下載的檔案。防護永遠該做在應用層，別把使用者網址直接交給轉換器；但當依賴本身會在你不知道的角落替你開連線時，庫內多一層預設拒絕就是多一道保險。順帶一提，這也是「Excel 處理庫」與「Excel 處理工具」的分界：前者跑在你的伺服器行程裡，它的網路行為就是你服務的網路行為，這類風險不會因為它是「處理試算表的」就比較溫和。

搬家要動的地方比想像少，最痛的是 slf4j

Fesod 官方的遷移文件把話說得很滿：核心 API、註解與處理邏輯不變，遷移主要是換依賴座標加改 import。我實際解開 fesod-sheet-2.1.0.jar 檢查，org.apache.fesod.sheet.FastExcel 這個入口 class 確實還在，官方把它保留成過渡期的相容別名，甚至有人寫了 OpenRewrite 配方，能把 FastExcel 1.3.0 的專案自動改寫到 Fesod 座標，Maven 與 Gradle 都涵蓋。

改動本身是機械工程：

<!-- 改前 -->
<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>easyexcel</artifactId>
  <version>4.0.3</version>
</dependency>

<!-- 改後 -->
<dependency>
  <groupId>org.apache.fesod</groupId>
  <artifactId>fesod-sheet</artifactId>
  <version>2.1.0-incubating</version>
</dependency>

import 前綴從 com.alibaba.excel 換成 org.apache.fesod.sheet，EasyExcel.read(...) 這類呼叫換成 FastExcel.read(...) 或 FesodSheet.read(...)，註解與 Listener 寫法照舊。環境條件不苛：官方標示 Java 8 以上即可，授權前後都是 Apache-2.0，商用沒有新增限制。

解 jar 時還看到兩個對遷移有意義的細節。其一，com.alibaba:easyexcel 主座標本身就是個 2.6KB 的空殼聚合器，真正的程式碼在 easyexcel-core（540KB），所以別被「我只有 import easyexcel」迷惑，遷移時兩個座標都要清。其二，easyexcel-core 4.0.3 的 pom 裡還帶著一條 easyexcel-support:3.3.4 依賴，版號停在 3.x，和主座標的 4.0.3 不同步，這種版本錯位就是專案凍結狀態下常見的死角，沒有人會再去對齊它。

真正容易咬人的在依賴樹底層。對照兩版 pom：easyexcel-core 4.0.3 帶的是 POI 5.2.5 與 slf4j-api 1.7.36；fesod-sheet 2.1.0 帶 POI 5.5.1 與 slf4j-api 2.0.20。POI 小版升級通常平順，但 slf4j 從 1.x 跳 2.x 換掉了綁定機制，如果你那個年代的專案還掛著 log4j 1.x 的舊綁定或 slf4j-log4j12 這類 bridge，遷移那天要先把它們清乾淨，否則會在各種 NoClassDefFoundError 裡繞圈。另外 Fesod 把原來的單體拆成 fesod-sheet、fesod-common、fesod-shaded 幾個模組，相依會自動帶進來，一般不用手動管理，但若你的公司有中央依賴鎖定清單，記得把新模組補進去。所以搬家不難，但請挑一個能跑完整測試的空檔做。

誰該現在動，誰可以先放在原地

回到一開始的判斷。

可以暫緩的情境：純內部資料流、檔案由自家系統產出、沒有任何 URL 型別欄位進入寫入路徑、且 4.0.3 的功能對你已經夠用。這種用法下，凍結的程式碼反而是種穩定，近九年累積的社群使用量也佐證了它在「內部批次讀寫」這個定位上的成熟度；真的需要搜尋跨工作表比對或圖片轉試算表這類周邊應用，可以先看我們先前寫過的 Diff Excel 兩份試算表逐格比對與圖片轉 Excel 的繁中表格實測。

該排搬遷的情境：服務會解析外部上傳的 Excel、匯出功能的圖片網址含使用者輸入、或你的合規要求依賴元件必須有在維護的安全修補線。落在這一側的場景並不少見，入口網站讓使用者上傳報表批次更新、電商後台把使用者頭像網址寫進對帳單、政府開放資料或 ERP 定時匯入的第三方檔案，全都算。這些場景踩的正是前面那節拆過的風險面，而 Fesod 2.1.0 的允許清單機制直接補在這個位置。另外兩種人可以順便重新評估手上的牌：已經在用 FastExcel（cn.idev.excel 座標）的，等於已經搬過一半，剩下換座標與 import 的收尾；還在裸用 POI 又常被記憶體逼瘋的，這條血統當年紅的理由（串流讀寫省記憶體）現在仍然成立，處理大檔翻譯前後的周邊工具鏈也可以回頭參考 DeeplxFile 的觀察。

還有一種灰色地帶：專案明年才要除役、資料量小、團隊沒有多餘人力。這種情況留下來完全合理，但建議至少做一件事，把「我們知道這個依賴已凍結」寫進技術債清單，而不是讓下一個接手的人在毫無心理準備下發現倉庫唯讀。

還沒拍板的事：孵化中的招牌，和你自己的測試

Fesod 的版本號至今掛著 -incubating 後綴，官網首頁也放著 Apache 基金會的標準聲明：孵化狀態不代表專案不完整，但代表它還沒通過基金會對治理穩定度的最終審核。對企業採購來說這是簽核欄位上的實際差異；對工程判斷來說，看它的發布節奏與修補速度（CVE 從修復合併到正式通告約四週，版本間距從月到季不等）比看招牌更準。若半年後它順利畢業拿掉後綴，這條顧慮就自動消失。

還有兩個問題沒有現成答案：一是效能，官方的記憶體與速度數字是專案方自述，你的資料形狀、欄位型別、JVM 版本都會讓結果漂移，搬遷前請用自己的最大檔案跑一輪；二是 API 完全相容是官方說法，這裡核對到的層級止於依賴座標、class 清單與入口別名，重要專案請把遷移當成一次需要測試覆蓋的重構，而不是文字替換。

打開你的 pom 搜 easyexcel，這個動作三十秒，而它決定的是你接下來要不要開一張搬家的票。