目录
  • 解析
  • 检查
    • 1.本地的go编译器版本
    • 2.go module构建模式未开启
    • 3. 是否在go.mod所在目录执行的go mod tidy
  • 总结

    go mode tidy出现报错go: warning: “all“ matched no packages的解决方法

    查到的可能原因：
    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.11和Go1.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

    go mode tidy出现报错go: warning: “all“ matched no packages的解决方法

    2.go module构建模式未开启

    保险起见

    win

    set GO111MODULE=auto

    linux

    export GO111MODULE=auto

    果然没有用

    go mod指令

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

    发现是第三个原因

    go mode tidy出现报错go: warning: “all“ matched no packages的解决方法

    应该在douyinService下执行而不是DouYin

    总结

    声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。