这是一篇踩完 Go dep 这个官方包管理器的坑之后的半吐槽文（人畜无害，看看就好 ：））。
一直以来，Go语言的『包管理器』这个问题，都没有得到有效地解决，当 pip 和npm 在天上飞行的时候，Go语言的包管理就像在地上爬行一样。
你当然可以无脑 go get ，毕竟是内置的，钦定的。然而，一旦涉及到团队合作时，由于 go get 无法有效控制依赖包的『版本语义管理』，别人很有可能无法100%搞成和你一样的环境。然后，某些诡异的Bug，就从这里产生了。那么怎么做才能保证 100 %可靠呢？直接将被依赖包的源代码也提交到 Git 里面， 让被依赖包也成为版本管理的一部分。好吧，这种蠢萌蠢萌的做法，既简单粗暴，还不会出错，我待过的一个团队就是这样做的（项目几乎不会升级被依赖包）。
然而，有很多人觉得将第三方包的源码也提交到Git中，是一种非常 Stupid 的做法（壮士，你敢将 node_modules 下面的代码提交到贵司的Git中去吗）。于是，各种各样的『社区解决方案』就出现了，“百家争鸣”。比如，你走运的话，可以搜索到这样的文章标题：
- Why I Use Godep？
- Why Glide is Better than Godep?
- Migrate from godep
balabala...
“这么多的解决方案，可真是挑花了朕的眼睛呀。” 你感叹道。如果你因为某种契机，更换了几个主写Go的团队（可能是不同公司），那么可能这些包管理器你都要使用一次。“重在参与嘛，反正又不难，多学点知识总是最好的。” 大V级程序员这样教导你。
是啊，确实不难，费不了多少时间。可是，你抱怨的主题可能是『马蛋，一个包管理器而已，至于整出这么多花样吗，难道不应该是语言自带，官方独裁维护的吗，难道不是 install uninstall 一把梭吗』。只是，大V级程序员没有听懂，以为『这个年轻人浮躁，不愿意学习』。
于是，Go dep出来了。附带还有几篇文章，说包管理是如何如何复杂的一件事情，dep 这个工具是如何如何地牛逼。如果你像我一样，是一个压根没有任何动力，去了解这件事情如何复杂如何牛逼的小白，奋力膜拜大佬，给大佬递茶，就完事了。只是呢，Go dep这个工具，还没有完全进入官方的工具链中，而且使用方式有点怪怪的。
“没事的，大佬们一定会出一篇文章，分析为什么这样是最牛逼的，Go语言很多特性都没有，你不也一样被洗成了脑残粉了吗？ ：）” 你这样想。（绝对没有黑得意思，我已经写了挺多Go代码了，就是 if err != nil 打得有点手疼 ）。
对于我这种只会npm install的人来说，是绝对没有动力去了解 npm 这个工具的来龙去脉，前后关系的，但是Go 语言，也许就要花上一整大段时间，去Google清楚这中间七七八八的琐碎事。
所以说，还真有点怀念 npm 呢。