亲宝软件园·资讯

展开

go mode tidy报错解决

折叠的饼干 人气:0

查到的可能原因
1.本地的go编译器版本
2. go module构建模式未开启
3. 是否在go.mod所在目录执行的go mod tidy

解析

一开始发布的时候 一开始go发布的时候是没有包管理的
go get命令会根据路径,把相应的模块获取并保存$GOPATH/src
也没有版本的概念,master就代表稳定的版本
后来引进了Go Module 在GO1.11引入,不再是只有一个版本了,利用go.mod记录每个包的版本

于是问题就来了


到底是按照$GOPATH的规则走还是按照Go Module来呢?

GO111MODULE是一个环境变量,用于改变go引入包的方式

Go1.11Go1.12

GO111MODULE=on
这个设置会强迫使用Go modules,即使项目在你的GOPATH里。需要go.mod才能工作。
GO111MOUDLE=off,使用GOPATH的方式,即使在GOPATH外边
GO111MODULE=auto,默认设置。

当你不在GOPATH内的时候,就类似GO111MODULE=on

当你在GOPATH内的时候,即使存在go.mod,也是GO111MODULE=off的效果

当你在GOPATH内,然后你需要GO modules来做一些操作的时候(如go get一个特定的版本),那就需要这么干:
GO111MODULE=on go get xxxxx


Go 1.13,auto的意思改变了: 如果找到了go.mod,或者在没有go.mod,但是在GOPATH外,那效果就是GO111MODULE=on(强迫使用go module)。所以你可以把所有的仓库都保存在你的GOPATH

why?
没有go.mod的时候,在GOPATH里,效果就是GO111MODULE=off(获取包并放在$GOPATH/src/)

检查

1.本地的go编译器版本

项目版本是1.16,这里有go.mod默认为GO111MODULE=on

2.go module构建模式未开启

保险起见

win

set GO111MODULE=auto

linux

export GO111MODULE=auto

果然没有用

go mod指令

3. 是否在go.mod所在目录执行的go mod tidy

发现是第三个原因

应该在douyinService下执行而不是DouYin

总结

加载全部内容

相关教程
猜你喜欢
用户评论