GitHub把45GB"過期"文件藏了10個月，開發者賬單照扣

你的GitHub Actions存儲配額在悄悄燃燒，而元兇可能是一堆已經被標記為"過期"的文件。開發者jefflongo最近收到一封警告郵件：他的組織每天產生約45GB·小時的存儲消耗，來自一個已經10個月沒跑過任何Action的倉庫。更詭異的是，那些舊工作流的產物早就設了1天過期，UI上也明明白白顯示"已過期"。

賬單照扣，文件卻"死而不僵"。這個案例在GitHub社區論壇炸出了大量同病相憐的開發者——原來"過期"和"刪除"之間，隔著一條GitHub沒寫進文檔的灰色地帶。

幽靈文件：UI說沒了，服務器說還在

社區成員BryanBradfo點破了核心問題：GitHub后端存在一個已知的故障——界面正確標記產物為"過期"，但物理文件仍留在服務器上。這些"幽靈文件"繼續占用磁盤空間，并計入你的配額。

換句話說，你看到的"已過期"只是數據庫里的一條狀態記錄，真正的清理可能還在排隊等后臺任務執行。

大規模平臺的垃圾回收從來都不是即時完成的。GitHub依賴后臺作業清理數據，而"過期"到"物理刪除"之間的延遲可能長達數周甚至更久。在這段" limbo 期"里，數據既不可見、不可用，卻依然計費。

jefflongo的45GB·小時/日消耗，正是幽靈文件在暗處持續計費的典型癥狀。按GitHub Actions存儲定價推算，這種隱形消耗每月可能燒掉數百美元，而開發者渾然不覺。

計費陷阱：時間加權，而非快照

社區用戶ash-iiiiish揭示了一個更隱蔽的機制：產物存儲計費采用時間加權模式，而非簡單的時點快照。這意味著刪除操作只能阻止未來的累積，無法抹除已經產生的歷史消耗。

舉個例子：一個10GB的產物存放30天后被刪除，你的賬單會完整記錄這300GB·日的使用量，而不是刪除后歸零。很多開發者誤以為"刪掉就停費"，實際上是在為過去的時間買單。

更麻煩的是，存儲配額不止包含構建產物。工作流日志、緩存、運行元數據同樣吃空間，且清理規則各不相同。一個倉庫看似"干凈"，這些附屬數據可能仍在后臺堆積。

jefflongo的倉庫雖然產物過期，但10個月的歷史運行記錄、調試日志、依賴緩存很可能從未被清理——它們不會出現在產物列表里，卻默默貢獻著存儲數字。

止損方案：從被動等待到主動獵殺

社區討論中涌現了幾條實戰策略，核心思路是繞過GitHub的自動清理，手動確保數據真正消失。

對于產物，不能依賴過期策略，需要主動調用API刪除。GitHub REST API提供刪除產物端點，配合腳本定期掃描倉庫，可以強制物理清理。有開發者分享了Python腳本，遍歷所有工作流運行并批量刪除產物，執行后配額立即下降。

對于日志和緩存，需要分別處理。工作流日志默認保留90天，可通過設置`retention-days: 1`縮短，但歷史日志仍需手動清理。依賴緩存（Actions Cache）則完全獨立，需要額外調用緩存API刪除。

最激進的方案是定期歸檔并刪除整個倉庫。對于確實不再維護的項目，這是唯一確保零消耗的方式——畢竟GitHub不會為已刪除的倉庫計費。

一個細節值得注意：jefflongo提到他的產物明確設置了1天過期，卻依然產生費用。這說明即使配置正確，GitHub的清理延遲也可能超出預期。社區建議將過期策略視為"兜底"而非"保險"，主動清理才是可控方案。

GitHub官方文檔對此事保持沉默，既未承認幽靈文件問題的普遍性，也未給出清理延遲的具體時間范圍。開發者的唯一武器是社區經驗——以及定期檢查賬單的習慣。