大家好，我是煎鱼。
作为一个资深的 “技术客服”（经常回答处理各种问题），前段时间遇到了一个比较无语的事情。还埋伏了挺久。
在我朋友他们当年搭建微服务生态时，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 的缓存机制下有所兜底，否则免不了又是一次许多人介入的更新。或者再加一层的其他方案了。
