Go micro/cli 很不专业，居然直接删库了！

大家好，我是煎鱼。

作为一个资深的 "技术客服"（经常回答处理各种问题），最近遇到了一个比较无语的事情。还埋伏了挺久。

在我朋友他们当年搭建微服务生态时，go-micro 是非常火的，也没有那么多其他 Go 框架的竞争对手。因此很多第三方库（例如：这次遇到是 sentinel 的库）有直接或间接依赖到他们。

但没有想到，最近有同学反馈自己在新环境运行程序后报错了。我一看，go-micro 组织下的这个库：github.com/micro/cli 竟然 "删库跑路" 了。。。

对应到程序里，执行 go mod tidy 命令后，会报如下报错：

css 复制代码

github.com/micro/cli/[email protected]: invalid version: unknown revision v2.1.2
...

真的是挺无语的。

那为什么 micro/cli 要删库呢？我翻了一圈，好多人在 issues 提出了疑问。

官方给出了答复：

原因是："由于维护不善，已被弃用。"

这里最无语的是，弃用完全可以理解。但作为知名开源组织，有人引用和大量下载的情况下，竟然直接删库了，是非常的不讲武德的。

合理的调整，应该要把仓库转成归档仓库（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，便不会有任何的感知。后面在渐进式的慢慢升级就好了。

总结

一个知名开源库的维护是否标准，对于上下游的框架和工具均有一定的影响。对于这次发现 go-micro 直接删掉一个有近 20w 次下载的库，还是比较失望的。

在相关 issues 里也看到了不少国外开发者的无语。幸亏这次在 goproxy.cn 的缓存机制下有所兜底，否则免不了又是一次许多人介入的更新。或者再加一层的其他方案了。

文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blo... 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。