11--go mod遇到的小问题 ｜ 青训营笔记

这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天

gopath 不起作用

 cannot find module providing package github.com

原因：使用代理下载go包后后，出现了找不到包的问题，后来发现若使用代理，他会去pkg包下找依赖。

解决：在使用 GOPROXY 的时候，开启了 GO111MODULE，导致包管理非官方所说的在 GOPATH\src\，而是去了 ​GOPATH\src\pkg\目录下，需要用go mod引入这些包 require github.com/gin-gonic/gin@latest ，解决import获取不了包的问题。运行：

  go mod init gin
  go mod edit -require github.com/gin-gonic/gin@latest

package main划红线

并提供了一个文档，以下进行了翻译：

设置工作区

gopls支持 Go 模块和 GOPATH 模式。但是，它需要一个定义的范围，引用、重命名和实现等语言功能应在其中运行。

以下选项可用于配置此范围：

模块模式

一个模块

如果使用单个模块，则可以打开模块根目录（包含文件的目录）、模块内的子目录或包含模块的父目录。go.mod

注： 如果打开包含模块的父目录，则该目录必须仅包含该单个模块。否则，您将使用多个模块。

多个模块

Gopls有几种同时处理多个模块的替代方案，如下所述。从 Go 1.18 开始，Go 工作区是首选解决方案。

Go 工作区 （Go 1.18+）

从 Go 1.18 开始，该命令通过 go.work 文件原生支持多模块工作区。这些文件由以 开头的 gopl 识别。go``gopls@v0.8.0

因此，在 Go 1.18 及更高版本中处理多个模块的最简单方法是创建一个包含您要处理的模块的文件，并将工作区根目录设置为包含该文件的目录。go.work``go.work

例如，假设此存储库已签出到目录中。我们可以同时处理两者，方法是使用 创建一个文件，然后将包含文件的目录添加到工作区：$WORK/tools``golang.org/x/tools``golang.org/x/tools/gopls``go.work``go work init``go work use MODULE_DIRECTORIES...``go.mod

 cd $WORK
 go work init
 go work use ./tools/ ./tools/gopls/

...然后在我们的编辑器中打开目录。$WORK

易得原因：go module模式是分为两种的，分别是单模块和多模块

单模块是指该文件及其子目录下只能有一个go.mod文件，如果新建包或者移动到该目录下，会构成子代嵌套，依旧视为是一个module。多模块是默认关闭的，所以要手动打开，一般官方推荐的方法是采用工作区的方式，也就是为每个模块创建一个工作区文件夹，这样每个模块都会有自己的作用域，并且不会垮模块工作。

解决：

在vscode的设置-拓展-Go-Alternate Tools的setting.json中加入：

 "gopls": {     
     "experimentalWorkspaceModule": true,
 },

保存，然后重启vscode，重新导入工作文件夹即可。

go mod twice in the workspace

原因：go mod init 创建工程时，在工程目录下生成一个pkg的目录，将工程所用到的包下载此目录。而go在安装时，会在gopath的全局目录中生成一个pkg目录，因sqlite3的版本有升级，在go build时会自动下载升级的最新包，从而导致出现twice in the workspace.

解决：

1、删除工程目录下的pkg目录

2、在工程的go.sum文件中找到有两个版本的信息的组件包，删除不需要的版本信息。

3、到gopath的pkg\mod及pkg\cach目录下删除对应的版本目录。

4、重启vscode，build，会自动下载所缺的包。

version "latest" invalid: must be of the form v1.2.3

原因：新版本的包被墙了，拉不到。

解决：

手动加入被墙的包（原始包），一定要记住版本号，实在不知道的话，就试试v0.0.0，然后重新build。