大家好，我是煎魚。

作為一個資深的 “技術客服”（經?；卮鹛幚砀鞣N問題），前段時間遇到了一個比較無語的事情。還埋伏了挺久。

在我朋友他們當年搭建微服務生態時，go-micro 是非常火的，也沒有那么多其他 Go 框架的競爭對手。因此很多第三方庫（例如：這次遇到是 sentinel 的庫）有直接或間接依賴到他們。

但沒有想到，最近有同學反饋自己在新環境運行程序后報錯了。我一看，go-micro 組織下的這個庫：github.com/micro/cli 竟然 “刪庫跑路” 了。。。

圖片

對應到程序里，執行 go mod tidy 命令后，會報如下報錯：

github.com/micro/cli/v2@v2.1.2: invalid version: unknown revision v2.1.2
...

真的是挺無語的。

那為什么 micro/cli 要刪庫呢？我翻了一圈，好多人在 issues 提出了疑問。

官方給出了答復：

圖片

原因是：“由于維護不善，已被棄用。“

這里最無語的是，棄用完全可以理解。但作為知名開源組織，有人引用和大量下載的情況下，竟然直接刪庫了，是非常的不講武德的。

圖片

goproxy.cn 的模塊統計數據

合理的調整，應該要把倉庫轉成歸檔倉庫（Archiving repositories），對于用戶較為友好。

這個問題，解決方向一般有以下幾種：

1、萬能 replace 和升級間接依賴庫：

這種情況下，直接在 go.mod 文件，把有問題的庫 replace 掉就可以了。

像本文的例子，官方是建議 replace 為 github.com/urfave/cli/v2 即可。

顯然遇到這種問題的，更多的是大量的存量程序。個人覺得這非常治標?？偛荒苊總€新同學來跑程序都要卡一會吧。??

所以這個方案對于存量程序來講，如果出問題的人都要 replace 一遍，那還不如直接當時就讓他升級庫，把依賴去掉了。

2、換合適的 GOPROXY 源：

這個朋友一開始 GOPROXY 用的是 goproxy.io，但是這個鏡像加速是不會對已刪除庫進行緩存的（或者會失效？）。我們只需要切換為 goproxy.cn 即可。

他在切換 GOPROXY 后，源庫被刪除的 micro/cli/v2 正常拉取。萬事大吉。因為 goproxy.cn 會對已刪除的庫有緩存機制。做好了兜底策略。

這個方案可能是較為無感的。對于存量的同學來講，如果一開始就使用的是 goproxy.cn，便不會有任何的感知。后面在漸進式的慢慢升級就好了。

另外其產線 CICD 配置的也是 goproxy.cn，所以一直沒有被人發現。直至最近有人換新電腦新環境，重新配置時才遇到。

總結

一個知名開源庫的維護是否標準，對于上下游的框架和工具均有一定的影響。對于這次發現 go-micro 直接刪掉一個有近 20w 次下載的庫，還是比較失望的。

在相關 issues 里也看到了不少國外開發者的無語。幸虧這次在 goproxy.cn 的緩存機制下有所兜底，否則免不了又是一次許多人介入的更新?；蛘咴偌右粚拥钠渌桨噶?。