楔子
在项目开发中我们会引入自己的私有库代码,这个私有库代码由gitlab、gitea等服务托管。我们想通过go get 以及潜在拉取代码命令去拉取代码时解决不能下载访问问题，有此记录在此，以下只针对go module版本做论述。
正文
前提条件：
1.配置好GOPATH环境
2.支持go module版本也就是golang >= 1.11以上
方案一：
我们可以采用go vendor(需要golang>=1.6版本)包的方式，把我们依赖的私有库代码放入到vendor中。
优点:
1.在网络不好的状况下、或者无网编译、拉取代码不方便的情况下适用(比如国企业务场景)。
2.代码能正常引用，不需要更改go.mod文件
缺点:
1.如果微服务多实例，每次更新部署都需要copy一份vendor包。
2.如果依赖的代码频繁修改发布，每个服务实例也需要copy一份覆盖。
方案二：
采用go module提供的replace替换修改go.mod文件引用包的方法来解决。具体方法也是把依赖的库下载到本地目录中,任意目录即可，也可以是gopath目录中，和vendor思想雷同。
优点:
1.同上文方案一vendor
缺点:
1.同上文方案一vendor
2.会存在找不到替换引用的代码包。通常我们开发代码都是在本地,我们的私有库都是公司内网可以访问的，可能因为一些原因你本地访问不了内网或者无法拉取私有库代码，为了能让代码在本地开发环境运行起来我们可提前下载好依赖包,然后用replace替换引用到这个下载的代码包，这是replace替换功能的真正用途。重点来了，我们每次开发完成之后提交代码需要修改go.mod replace 把replace删除掉在提交或者修改replace替换地址，不然放到线上服务器运行会出错，会提示缺少代码依赖包文件找不到相关错误，当然这个错误很好解决，你可以约定好目录在线上服务器以同样的方式和目录下放入依赖代码，这样replace就能找到依赖代码了。至于为什么要删掉或修改replace，因为每个人的本地环境不同存放依赖库代码位置也不同，因此replace替换地址也不同。以上这也是一种方案，但是你有没有发现这又退化回vendor复制粘贴问题了。
方案三:
终极方案，配置go的GOPRIVATE
1.步骤一
配置golang环境变量。使用go命令 go env 查看环境变量是否设置成自己的私有代码库地址
为空则未设置，或者已经设置想修改替换则使用以下命令
go env -w GOPRIVATE=gitlab.xxx.com //gitlab.xxx.com为你引用的私有库
ps:早期旧版本golang不支持 -w参数,大概golang1.14版本之后有此功能需要注意！低版本可以采用环境变量export方式设置,或者修改profile文件
其中我们可以使用模糊匹配方式比如*.开头。然后我们执行命令查看是否设置成功，使用go env命令如下
ok此时代表设置成功。
2.步骤二
配置git配置文件。linux切换到 ~/.gitconfig目录文件下，如果没有则在该目录创建此文件。然后打开此文件准备添加内容。我们clone代码访问有两种方式一种是ssh访问，一种https，以下针对这两种配置进行说明
ssh：
[url "ssh://git@github.com:"]
insteadOf = https://github.com/
如果我想配置某个github组织下面的仓库，可以这样
[url "git@github.com:exampleOrg"]
insteadOf = https://github.com/exampleOrg
由于我的是GitHub代码托管平台，所以配置的是github.com域名，如果是gitlab则配置自己搭建的gitlab域名地址，其他gitea诸如此类
测试访问连通性
ssh -T git@github.com
如输出类似内容基本就成了
Hi chaunsin! You've successfully authenticated, but GitHub does not provide shell access.
https:
https方式默认会读取 $HOME/.netrc 文件,如果是类unix系统，如果是Windows则在 %USERPROFILE%\_netrc中，如果没有可以创建此文件，然后在netrc文件中填写用户名密码
machine github.com
login {用户名}
password {密码}
到此基本已经结束，此时我们再拉取代码不出意外基本成功，如何验证是否成功则可以使用以下命令：
go mod tidy
具体操作就是拉取依赖代码，对依赖包文件进行增加或者删减，同时检验go.mod文件的正确性,并对其修改引用。
然后我们可以看见如下信息
优点：
1.每次升级部署无需copy代码，只需要在go.mod中指定代码依赖版本即可
2.无需每次修改go.mod文件
3.一劳永逸
缺点
1.配置流程较为麻烦，只配置一次但还可以接受
2.如果程序代码部署到多台物理机，每台物理机需要安装配置git以及配置环境变量等，如今有docker等镜像制作方式这点也可以接受。
提示: 有的时候可能设置好了私钥等配置但是还是不能拉取下来代码,可以尝试清理构建得缓存内容，使用golang命令 go clean -modcache 方式具体参考go clean命令
总结
以上列举出了针对私有库拉取代码的实现方案，并对每种方案的优缺点说明进行了总结，其中本文并没有对曾经的代码管理方式dep来进行说明，此方案golang官方已经废弃，因此在这里不在赘述。
参考文章
https://go.dev/doc/faq#git_https
https://go.dev/ref/mod#private-modules
https://zhuanlan.zhihu.com/p/646336183?utm_id=0
https://blog.csdn.net/xcbeyond/article/details/132233404
完~
