大家好，我是煎魚。

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

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

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

圖片

對應(yīng)到程序里，執(zhí)行 go mod tidy 命令后，會報如下報錯：

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

真的是挺無語的。

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

官方給出了答復(fù)：

圖片

原因是：“由于維護不善，已被棄用?！?/p>

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

圖片

goproxy.cn 的模塊統(tǒng)計數(shù)據(jù)

合理的調(diào)整，應(yīng)該要把倉庫轉(zhuǎn)成歸檔倉庫（Archiving repositories），對于用戶較為友好。

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

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

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

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

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

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

2、換合適的 GOPROXY 源：

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

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

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

另外其產(chǎn)線 CICD 配置的也是 goproxy.cn，所以一直沒有被人發(fā)現(xiàn)。直至最近有人換新電腦新環(huán)境，重新配置時才遇到。

總結(jié)

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

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