这是我参与「第五届青训营 」伴学笔记创作活动的第 4 天。
- 下一个常见是的是incompatible，主版本2+模块会在模块路径增加/vN后缀，这能让go module按照不同的模块来处理同一个项目不同主版本的依赖。由于gomodule是1。11实验性引入所以这项规则提出之前已经有一些仓库打上了2或者更高版本的tag了，为了兼容这部分仓库，对于没有go.mod文件并且主版本在2或者以上的依赖，会在版本号后加上+incompatible 后缀 前面讲语义化版本提到，对于同一个库的不同的major版本，需要简历不同的pkg目录，用不同的gomod文件管理，如下面仓库为例，V1版本gomod在主目录下，而对于V2版本，则单独简历了V2目录，用另一个gomod文件管理依赖路径，来表明不同major的不兼容性。那对于有些V2+tag版本的依赖包并未遵循这一定义规则，就会打上标志， 增加一个compatile的case
- gomodule的依赖分发。也就是从哪里下载，如何下载的问题~
- github是比较常见给的代码托管系统平台，而Go Modules 系统中定义的依赖，最终可以对应到多版本代码管理系统中某一项目的特定提交或版本，这样的话，对于go.mod中定义的依赖，则直接可以从对应仓库中下载指定软件依赖，从而完成依赖分发。
- 但直接使用版本管理仓库下载依赖，存在多个问题，首先无法保证构建确定性：软件作者可以直接代码平台增加/修改/删除 软件版本，导致下次构建使用另外版本的依赖，或者找不到依赖版本。无法保证依赖可用性：依赖软件作者可以直接代码平台删除软件，导致依赖不可用；大幅增加第三方代码托管平台 压力。
- 而go proxy就是解决这些问题的方案，Go Proxy 是一个服务站点，它会缓源站中的软件内容，缓存的软件版本不会改变，并且在源站软件删除之后依然可用，从而实现了供“immutability”和“available”的依赖分发；使用 Go Proxy 之后，构建时会直接从 Go Proxy 站点拉取依赖。类比项目中，下游无法满足我们上游的需求，***
- go proxy的使用，Go Modules通过GOPROXY环境变量控制如何使用 Go Proxy；GOPROXY是一个 Go Proxy 站点URL列表，可以使用“direct”表示源站。对于示例配置，整体的依赖寻址路径，会优先从proxy1下载依赖，如果proxy1不存在，后下钻proxy2寻找，如果proxy2，中不存在则会回源到源站直接下载依赖，缓存到proxy站点中。 子标题细化 变量和proxy
