周下載 60 萬，但作者刪庫！我從本地 pub 快取把它救出來，順手備份到自己的 GitHub

經過

今天在社群閒逛時，順手看了一眼群裡，有人說「get 作者刪庫跑路了！」我起初保持懷疑，打開 pub 頁面還能打開，

我心裡想：（這個套件每週下載接近 60 萬，拿到 15.5k 的 star，且 getx 是 Flutter 四大狀態管理套件之一，時至今日還有很多使用者。我自己做專案，也在把 getx、provider、riverpod、bloc 做技術選型，橫向比較……）

作者跑路等於在 Vue 生態裡的 vuex、pinia 跑路，真的很誇張……

當我又打開作者的 GitHub 時，迎接我的就是 404 的畫面：

我心中暗叫不妙，這種情況最怕的不是「今天能不能跑」，而是過一段時間你換電腦、CI 重裝、同事新拉專案時，大家突然開始補依賴、找原始碼、翻快取，最後整個團隊卡住。

我這邊的處理方式很簡單：既然本地還能跑，那就先把本機已經快取下來的完整套件撈出來，備份到自己的 GitHub，至少之後有個穩定來源。

我已經把這份 get 4.7.3 傳到這裡：

https://github.com/xinqingaa/get-4.7.3

如果你們團隊有人懶得自己再走一遍「翻快取、複製目錄、初始化 Git、上傳倉庫」這套流程，其實可以直接用我這個遠端位址，先把專案跑起來再說。

先說結論

這裡有一點要先說清楚：

GitHub 倉庫 404，不等於 pub.dev 上的 hosted 套件馬上就拉不下來。

只要 pub.dev 上這個版本還在，你專案裡原本寫的：

get: ^4.6.6

很多時候依然可以正常執行 flutter pub get。

所以我這次做這件事，不是因為「今天已經完全裝不上了」，而是因為原始碼倉庫、歷史 issue、後續修補、團隊兜底等事情一下子都變得不確定。

說白了，我不是在搶救一個已經完全消失的套件，我是在為未來留後路。

這次我主要確認了幾件事：

1. 專案雖然在 pubspec.yaml 寫的是 get: ^4.6.6，但我本機實際鎖定到的是 4.7.3。
2. 本地 pub 快取裡確實還有完整原始碼，路徑在 ~/.pub-cache/hosted/pub.dev/get-4.7.3。
3. flutter clean 不會把全域的 pub 快取刪掉。
4. 真正決定後續依賴從哪裡拉的，不是 flutter clean，而是 pubspec.yaml 裡到底寫的是 hosted 依賴還是 git 依賴。
5. 真正能證明「依賴來源切換成功」的，不是口頭說改了設定，而是 pubspec.lock 裡的 source 會從 hosted 變成 git。

這個差別其實很關鍵。

因為很多人看到專案出問題，第一反應就是先 flutter clean，但它處理的事情和「依賴從哪裡下載」其實不是一回事。

pub 快取到底是什麼東西

只要你在 Flutter 專案裡執行過 flutter pub get，依賴通常會被下載到本機的 pub 快取目錄。

macOS 下常見路徑就是：

~/.pub-cache

像從 pub.dev 拉下來的套件，通常會放在：

~/.pub-cache/hosted/pub.dev/

比如我這次找到的是：

/Users/lrq/.pub-cache/hosted/pub.dev/get-4.7.3

這個目錄不是一個「殼」，而是完整的套件內容，你可以看到：

• lib
• test
• example
• documentation
• pubspec.yaml
• LICENSE
• README.md

也就是說，只要你本機的快取還在，很多時候就還有機會把套件完整救出來。

我這次為什麼還能把 get 撈出來

因為我的專案之前已經跑過，這個套件已經被下載到本地了。

即便現在原作者倉庫不穩定，或你單純不想繼續依賴外部不確定因素，只要本機快取裡還留著這份程式碼，就可以複製出來自己維護。

我最後確認到的版本不是 4.6.6，而是 4.7.3。這也很正常，因為 pubspec.yaml 寫的是：

get: ^4.6.6

這代表允許拿 4.x 範圍內相容的更新版本。只要鎖檔 pubspec.lock 已經解析到 4.7.3，專案實際跑起來用的就是 4.7.3。

所以這次我沒有死守 4.6.6，而是直接把本機正在用的 4.7.3 備份走了。

我是怎麼備份到 GitHub 的

做法其實不複雜。

第一步：不要直接在 ~/.pub-cache 裡改東西。這個目錄本質上是快取目錄，不適合拿來當你自己的長期倉庫。

我先把它複製到自己維護的位置，例如：

mkdir -p /Users/lrq/work/vendor
cp -R /Users/lrq/.pub-cache/hosted/pub.dev/get-4.7.3 /Users/lrq/work/vendor/get-4.7.3

第二步：在複製出來的新目錄初始化 Git：

cd /Users/lrq/work/vendor/get-4.7.3
git init
git checkout -b main
git add .
git commit -m "chore: import get 4.7.3 from local pub cache"

第三步：推到自己的 GitHub：

git remote add origin https://github.com/xinqingaa/get-4.7.3.git
git push -u origin main

這樣做完之後，這個套件就不只是「還躺在我電腦快取裡」，而是已經有了我自己能控制的遠端倉庫。

如果大家都懶得操作，直接用我的遠端位址也行

這是最省事的辦法。

如果你們現在只是想先把專案跑起來，不想每個人都去翻 pub cache、複製原始碼、上傳一份倉庫，那可以直接把依賴改成我這個位址：

https://github.com/xinqingaa/get-4.7.3

pubspec.yaml 可以這樣寫：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

如果你們希望更穩定，不想之後有人往 main 推東西影響現有專案，那就不要寫 main，直接寫具體的 commit：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: 具體_commit_sha

這個方式更適合正式專案或多人協作。

因為一旦寫死 commit，之後即便倉庫繼續更新，你目前的專案也不會跟著變動。

這裡順便說清楚：flutter clean 到底是做什麼的

很多人會把 flutter clean 誤解為「把依賴也一起清掉」，其實不是。

flutter clean 的主要作用，是清理當前專案目錄下面的建置產物和暫存檔案。

它更像是在對當前專案說：
「你之前編譯留下來的東西先都別要了，等會兒我重新做一次。」

通常它會影響這些東西：

• build/
• .dart_tool/
• 一些 Flutter 建置過程中產生的中間檔
• 平台端的一些暫存產物

但有一點一定要注意：

flutter clean 預設不會刪除全域的 ~/.pub-cache。

也就是說，執行完 flutter clean 之後：

• 專案本地的建置狀態會被清掉
• 但你之前下載過的依賴快取，通常還在

所以它不會直接把我之前提到的 ~/.pub-cache/hosted/pub.dev/get-4.7.3 這個快取目錄刪掉。

那現在執行 flutter clean，會發生什麼

如果你目前專案狀態正常，執行：

flutter clean

你大概率會看到下面的結果：

1. 當前專案下的 build 目錄被清掉。
2. .dart_tool 下面很多重新生成用的檔案被清掉。
3. 下一次再跑專案時，Flutter 會重新做一輪初始化和建置。

但：

~/.pub-cache/hosted/pub.dev/get-4.7.3

這個目錄通常還在。

所以從「救套件」這個角度看，flutter clean 不是最危險的操作。

真正危險的是你手動把本地快取刪了，或是換了新機器，且你沒有自己的備份來源。

那現在執行 flutter pub get，又會發生什麼

這要分情況看。

情況一：你還沒改依賴，專案裡仍然寫著：

get: ^4.6.6

那 flutter pub get 做的事情大概是：

1. 讀取 pubspec.yaml
2. 結合 pubspec.lock 解析當前應該使用哪些版本
3. 檢查本機快取裡有沒有現成依賴
4. 如果快取有，就直接重用
5. 如果本機沒有，再去對應來源拉取
6. 重新生成 .dart_tool/package_config.json 等檔案

如果你的 pubspec.lock 裡已經鎖的是 get 4.7.3，而且本地快取也還在，那這一步通常不會有太大變動，多數情況是直接重用本地快取。

換句話說，flutter clean 之後再 flutter pub get，專案大概率還是能恢復起來。

情況二：你已經把依賴改成 GitHub 倉庫

例如你改成：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

這時候再執行：

flutter pub get

事情就變成另一套邏輯：

1. pub 會識別到這是一個 git 依賴
2. 它會去拉取這個 GitHub 倉庫
3. 然後把對應內容快取到本機
4. 更新鎖檔和專案依賴映射
5. 之後專案再編譯時，就會基於這份新的依賴來源來跑

也就是說，從此刻開始，專案依賴的就不再是「原本那個 hosted 套件來源」，而是你指定的這個 Git 倉庫。

這也是為什麼我說，真正決定依賴來源的是 pubspec.yaml，而不是 flutter clean。

所以 flutter clean + flutter pub get 連著執行時，應該怎麼理解

這兩個命令經常一起出現，但它們負責的事情完全不同。

你可以把它理解為：

• flutter clean：把專案現場打掃乾淨
• flutter pub get：按目前依賴設定重新把材料搬進來

如果你沒改依賴來源，它就繼續按原來的來源取。

如果你把 get 改成了你自己的 GitHub 倉庫，它就會按新的位址重新拉。

所以這套動作本身不可怕，關鍵是你在執行之前，pubspec.yaml 寫的是什麼。

我個人建議的處理方式

如果你只是想先保命，讓專案先穩住，我建議直接做兩件事：

1. 先把能找到的完整套件備份到自己的 GitHub。
2. 再把專案依賴切成你自己能控制的位址。

這樣做最大的好處是：

• 新同事拉專案時不用到處找快取
• 換電腦時不用賭本機有沒有舊依賴
• CI 重建時也不會因為某個外部倉庫狀態異常而臨時翻車

簡單來說，就是把「我電腦剛好還有快取」這件事，變成「團隊裡任何人都有穩定位址可用」。

如果你也想直接用我這份位址，可以抄這段

最省心的版本：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

改完之後執行：

flutter clean
flutter pub get

一般會發生這些事：

1. 當前專案建置快取被清理。
2. pub 按新的 Git 位址重新取得 get。
3. 鎖檔會更新成新的依賴來源。
4. 之後專案再跑，走的就是你指定的倉庫了。

如果專案比較重要，建議把 ref: main 換成具體的 commit。

GitHub 上的備註怎麼補

我建議至少補兩個地方：倉庫描述和 README.md。

1. 倉庫描述

在 GitHub 倉庫首頁右側 About 那裡，點編輯，簡單寫一句，例如：

Backup mirror of get 4.7.3 recovered from local pub cache.

這樣別人進來一眼就知道這個倉庫是做什麼的。

2. README

這個更重要，因為後面真正給別人複製依賴位址時，大家通常會先看 README。

可以直接把三件事寫清楚：

1. 這個倉庫是什麼
2. 它是從哪裡恢復出來的
3. 在 Flutter 專案裡怎麼引用

下面這段 README 你可以直接拿去用。

README 範例

get-4.7.3

這是從本地 pub cache 中恢復出來的 get 4.7.3 備份倉庫，用來做內部依賴兜底。

原始恢復來源：

• ~/.pub-cache/hosted/pub.dev/get-4.7.3

如果你想在 Flutter 專案裡直接使用這個倉庫，可以這樣寫：

dependencies:
  get:
    git:
      url: https://github.com/xinqingaa/get-4.7.3.git
      ref: main

如果用於正式專案，建議把 ref 改成具體的 commit SHA，避免後續分支內容變動影響建置結果。

如果你已經在本地把 README 改好了，上傳方式和平時推送程式碼一樣：

git add README.md
git commit -m "docs: add repository usage notes"
git push origin main

這就算把「備註」一起上傳了。

最後

這次事件也算給我提了個醒。

平時大家覺得依賴裝上了就完事了，但只要專案還在維護，關鍵依賴最好還是留一手。

尤其是那種在專案裡已經深度使用、短時間又很難替換掉的套件，真碰到上游不穩定，最省時間的方法不是現場慌，而是趁本機快取還在，趕快先救一份出來。

如果你們團隊現在也懶得自己再折騰一遍，那就先用我這份：

https://github.com/xinqingaa/get-4.7.3

先把專案穩住，比什麼都重要。

往期文章回顧

Flutter 圖片編輯器

• 掘金文章：https://juejin.cn/post/7571067260053585946
• pub.dev：https://link.juejin.cn?target=https%3A%2F%2Fpub.dev%2Fpackages%2Fflutter_img_editor
• GitHub：https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fxinqingaa%2Fflutter_img_editor

Flutter 全鏈路監控 SDK

• 掘金文章：https://juejin.cn/post/7564977973260173338
• pub.dev：https://link.juejin.cn?target=https%3A%2F%2Fpub.dev%2Fpackages%2Fflutter_monitor_sdk
• GitHub：https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fxinqingaa%2Fflutter_monitor_sdk

Flutter 全場景彈窗

• 掘金文章：https://juejin.cn/post/7538324216594726950
• pub.dev：https://link.juejin.cn?target=https%3A%2F%2Fpub.dev%2Fpackages%2Funified_popups
• GitHub：https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fxinqingaa%2Funified_popups

Flutter 日曆元件

• 掘金文章：https://juejin.cn/post/7531976064496123931
• pub.dev：https://link.juejin.cn?target=https%3A%2F%2Fpub.dev%2Fpackages%2Fomni_calendar_view
• GitHub：https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fxinqingaa%2Fomni_calendar_view

日期選擇器

• 掘金文章：https://juejin.cn/post/7524159959480991753
• pub.dev：https://link.juejin.cn?target=https%3A%2F%2Fpub.dev%2Fpackages%2Fomni_date_picker
• GitHub：https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fxinqingaa%2Fomni_date_picker

原文出處：https://juejin.cn/post/7628240893640376362