Go Modules是Go语言的官方包管理解决方案，自Go 1.11起逐步发展和完善。它解决了GOPATH限制和依赖管理的问题，允许用户在GOPATH外开发，实现依赖的版本控制和自动选择最小兼容版本，且提供了统一的管理方式。通过GO111MODULE、go.mod和go.sum等环境变量及文件，Go Modules简化了依赖管理和下载过程，尤其是通过GOPROXY解决了网络访问问题。
What Go Modules ？
Go Moudles是Go语言中正式官宣的项目依赖解决方案，发布于 Go 1.11，成长于 Go 1.12，丰富于 Go 1.13，目测完善于 Go2。可见其出生较晚，属于新时代的产物，并且有着官方的认证强推，是个十足的后浪了。
Why Go Modules?
为什么要用Go Modules，那么我们想想我们现在有什么待解决的痛点？
我是一名没成熟的小桔子，刚入职滴滴实习的第一天，安装go环境，打开go入门指南.pdf，当时最懵逼的一点就是，为什么要有GOPATH这个东西？我的所有代码还必须放在gopath下，这也太难受了，但是当我意识到GOPATH的必要性：
- 在Go中，import声明通过其完全限定的导入路径来引用包。GOPATH存在可以方便Go工具计算GOPATH/src内的任何目录所涉及软件包的绝对导入路径。
- 它是Go get命令存储包依赖项的位置。
我也只能认怂了，忍受住其带来的两个问题：
- GOPATH不允许开发人员像其他语言一样选择任意喜欢的目录签出项目的源代码。
- 此外，GOPATH不允许开发人员同时检出某个项目（或其依赖项）的多个副本
如果有一天，我的项目可以不用放在GOPATH下也不用去管理GOPATH环境变量，那我得省多少事儿！
过了第一天，在自己的努力下和同事们的悉心栽培下，我可算是能看懂go代码了，兴高采烈的看起了我们的围栏项目代码，发现这代码包里好大几个文件夹都是依赖的第三方库啊，这有github.com的开源库，也有git.xiaojukeji.com的内部代码库，这咋都提交到git了呢？这多冗余呀？不过当时的我肯定不管三七二十一，也照着弄吧。毕竟啥也不会的新人呢。果然，我刚拿起代码，学着用go get 取一下包，就无奈被墙了，哭了。随着能力的进步，老大交给我一个升级代码库的任务，由于围栏服务依赖了一个重要的开源库，而我们现在代码里面用的这个依赖包已经是很多年以前的了，很久没更新去拉取最新的commit了，我拿起git工具,git clone更新一波，放到压测平台一测，发现整体性能有很大提高，但是由于依赖的本地化，我们没有及时更新，这次的依赖更新算是延迟了很长时间了吧。
如果go能做到依赖包的及时更新和依赖冲突的自动选择，还不用担心从哪里找依赖包的问题，该有多好啊！
再等我现在实习半年了，偶尔看看go的开源库，发现如今go的开源库，都采用了不同的包管理方式，还得用不同的方式去下载依赖，这让我不禁期待一个官方认证的统一的go包管理方式了。
Fortunately，本周老大让我调研Go Modules，我发现这玩意儿正好解决了一直以来对go的这几个诟病：
总结
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
