记一次go module的坑

Posted 2023-03-11

参考技术A 事情是这样的，因为小马本次要写一个go项目。但是因为一些权限问题，一些依赖包在内网小马获取不到，于是只能求助大大。大大给的策略就是他先把所有的依赖包go mod,然后go mod vendor迁移到项目目录vendor下进行本地依赖载入即可，也就是使用 go build -mod=vendor来编译即可。一切似乎看起来还是那么完美。然后正要起飞，直接翻车，现场如下。【这里插播一条发现，就是使用golang IDE go build 和使用命令行go build 的区别在于前者不会生成.exe文件】

将大大go mod vendor完的包pull到本地，只要编译就会发生如下错误（以下省略了一部分类似的报错）。其实是 go.mod内的所有依赖包都报错。

大大说他的本地编译是正常的。不得不怀疑是不是因为大大本地gopath还有一份包依赖的原因，然而经查并不是这个问题。翻阅了网络上的大部分资料无果，网络上要么是说是因为识别不到包，按照提示重新go mod vendor一下就可以了。小马蛮试了一下，不出所料必然地报远程报获取不到呢，IDE的报错定位其实是不准确的。再次检查vendor/modules.txt文件，没有问题，无果。 于是开始质疑golang IDE 的版本支持问题，无果。看了下go.mod文件中写着go 1.14，也没错呢，小马用的GO SDK正是1.14.4版本。敲出go env 查看环境配置，GO111MODULE=on，因为环境变量是auto,但是go到一定版本后默认是on，也没问题，无果。那问题出在哪呢？由于没有依赖包拉取权限，只能再次求助大大，大大表示也很奇怪，一番折腾，于是问题得到解决。【这里插播一条好玩的东西，就是GO111MODULE为什么是GO111呢，因为其实1.11版本开始支持MODULE的】

结论是：因为大大go  mod的时候用的是go 1.13，而我编译的时候用的 1.14，所以就报了这个奇怪的错误。you what?直接懵逼。但是为啥go.mod文件中写的版本要求是1.14，而大大用1.13也编译得好好的。

这是个大坑，掉进坑里自己扑腾了一天！！希望大家谨慎入坑。

爬坑一小时出坑一秒钟，每一次的爬坑都是充满着十八般绝技。奇怪的姿势又增加了。

go运行方式有哪几种？

如果GO111MODULE是auto则根据项目目录位置和是否含有go.mod文件来决定使用什么模式。如果是GO111MODULE=off则使用gopath，如果是on则使用module模式。gopath模式下的src目录下不能有go.mod文件，否则报错。

一些go mod命令 记录备用，国内的资料并不多（注意go mod 命令在 $GOPATH 里默认是执行不了的，因为 GO111MODULE 的默认值是 auto。默认在$GOPATH 里是不会执行， 如果一定要强制执行，就设置环境变量为 on。）：