golang 的第三方包管理机制和 Python 有什么不同？
我一直用 Python ，对于其包管理方式熟悉和喜欢。
但是最近学习 golang 的时候，遇到了很多困惑，比如 golang 没有 python 的 pip 包管理器用来下载和管理第三方包，好像也没有一个 site-packages 目录统一存放这些第三方包，情况是这样的吗？
那请问 golang 是如何解决这些问题的呢？
参考一个知乎提问：golang的包管理模式设计的是否合理？
golang 貌似有一个 go mod，请问和这个是类似 pip 的东西吗？
回答：
先回答最后一个问题：是的，类似。
然后是正文部分。
Golang 的包管理机制一直是被人所诟病的，不是啥好设计。
这门语言本身就来自于 Google 内部需求，原型期压根就是 Google 专属的玩意儿。Google 大家都知道，monorepo 先行者和布道者，别说 Golang 项目了、全公司所有项目都在一个大 repo 下，任何修改代码的变更都要想办法保证整个 repo 不出问题，这种时候一个 $GOPATH 既省事儿、又够用，不需要关心依赖问题，简直完美。
但等到大家用 Golang 的时候，抓瞎了，想必你已经感受到痛苦了。
当然社区已经意识到这个问题了，所以也在努力尝试解决了，但这玩意儿吧肯定不是一蹴而就的。（类比 Node.js 里的 npm 有很多坑哔设计已经积重难返了）。
目前为止 Golang 已经经历过几个包管理机制了：
- 2012 年 Go 1.0 最早的
$GOPATH，全局依赖一把梭。 - 2015 年 Go 1.5 实验性引入、到 2016 年 Go 1.7 正式确定的
vendor，终于每个项目有自己单独的依赖管理了，但不好意思，还没有版本控制。 - 2017 年 Go 1.9 实验性引入的
go dep，后来因为社区与 Google 分歧过大，现在已经被砍了（这是归档仓库 https://github.com/golang/dep），不过总算有个比较成型的包管理了。 - 2018 年 Go 1.11 实验性引入、到 2019 年 Go 1.13 正式确定的
go mod，在 Golang 诞生的第 7 个年头，终于“千呼万唤始出来”了。
这些都是 Golang 官方团队出的，来自纯社区的方案就更多了，这里就不一一列举了。
此外，在 go dep、go mod 出现之前，为了解决依赖管理问题，社区内还流行过一段 Bazel（类似 Make 的一种构建系统，也是 Google 开源的），但这个东西就很重量级了，对于小项目来说也很不方便，但那能怎么办呢 —— 也没别的用啊 ?
就算是现在的 go mod，其实也有很多不完善的地方，比如无法引入两个版本不同的同名依赖等问题。总之未来还会有很长的一段路要走，也算是流行语言的必由之路吧。
回答：
现在几乎都是使用 go mod 。site-packages 在 go 里面同样有类似的。 执行go mod vendor 命令，会生成一个vendor目录，里面就是所有依赖框架的源码。
不要看以前过期的教程，执着于src目录。现在都快1.18了。好像是1.13版本go mod 就完善了。
以上是 golang 的第三方包管理机制和 Python 有什么不同？ 的全部内容， 来源链接： utcz.com/p/938327.html
