GO语言 | go work 神一般的管理多个module没烦恼

妖狐艹你老母 2024-04-07 12:21 23阅读 0赞

#### 文章目录 ####

*  前言
 *   *  go work工作区模式
 *  go work用法介绍
 *   *  go work init
     *  go work use
     *  go.work
 *  使用场景和最佳实践
 *   *  使用场景1
     *  使用场景2：同一个代码仓库里有多个互相依赖的Go Module
     *  使用场景3：切换依赖配置
 *  实战操作
 *   *  1 package name
     *  2 go mod init \*
     *  3 go work init \[path-to-module-one\] \[path-to-module-two\]
     *  4 main调用
     *  5 replace
     *  总结

## 前言 ##

最近手上有个活，需要自己本地包之间进行依赖

具体描述如下：

设计了如下目录结构，其中关注postman部分，要求核心程序放在internal文件目录，cmd目录存放一个cmd版本的main，wasm目录存放一个wasm版本的main，但cmd和wasm的main都依赖于internal目录下的程序实现。  
![在这里插入图片描述][e1eeb86bcbfa4730b2c418949b4c7d34.png]  
有了目标，原理上很简单，找到办法实现cmd可以导入internal包的方法就可以了

但是，就这么一个听起来很简单的目标，用过Go的都知道，虽然mod实现了Go的存放位置自由，但并没有解决全部问题，上述简单的梦想实现起来又得是各种左右摇摆的一通操作

在经过了艰苦卓绝的寻找之后

https://cloud.tencent.com/developer/article/1998266

https://zhuanlan.zhihu.com/p/109828249

这两篇文章详细介绍了如何跨文件目录进行本地包的操作，但是无奈本人抄都能抄错，就是没有办法完美实现两个目录包的调用，实现不了我理想中的状态，并且整个过程可以说是罗里吧嗦，这不科学

无意间发现了go在1.18版本更新了一个超级重磅的功能，那就是work！  
![在这里插入图片描述][5f97f50a03d44c9bb1786bbcdd6ff530.png]

看完了官方的描述，我确信，这就是我要找的人，国际惯例，还是原文地址先贴一下，外文好的，可直接一手理解

https://go.dev/doc/tutorial/workspaces

### go work工作区模式 ###

Go 1.18引入的工作区模式，可以让你不用修改每个Go Module的go.mod，就能同时**跨多个Go Module进行开发**。

**工作区里的每个Go Module在解析依赖的时候都被当做根Module。**

在Go 1.18以前，如果遇到以下场景：Module A新增了一个feature，Module B需要使用Module A的这个新feature，你有2种方案：

*  发布Module A的修改到代码仓库，Module B更新依赖的Module A的版本即可
 *  修改Module B的go.mod，使用replace指令把对Module A的依赖指向你本地未发布的Module A所在目录。等Module A发布后，在发布Module B的时候，再删除Module B的go.mod文件里的replace指令。

有了Go工作区模式之后，针对上述场景，我们有了更为简单的方案：你可以在工作区目录**维护一个go.work文件来管理你的所有依赖**。go.work里的use和replace指令会覆盖工作区目录下的每个Go Module的go.mod文件，因此没有必要去修改Go Module的go.mod文件了。

## go work用法介绍 ##

### go work init ###

使用go work init来创建一个workspace，go work init 的语法如下所示：

go work init [moddirs]

moddirs是Go Module所在的本地目录。如果有多个Go Module，就用空格分开。如果go work init后面没有参数，会创建一个空的workspace。

执行`go work init`后会生成一个`go.work`文件，go.work里列出了该workspace需要用到的Go Module所在的目录，workspace目录不需要包含你当前正在开发的Go Module代码。

### go work use ###

如果要给workspace新增Go Module，可以使用如下命令：

go work use [-r] moddir

或者手动编辑go work文件。

如果带有-r参数，会递归查找-r后面的路径参数下的所有子目录，把所有包含go.mod文件的子目录都添加到go work文件中。

如果某个Go Module的目录已经被加到go.work里了，后面该目录没有go.mod文件了或者该目录被删除了，那对该目录再次执行go work use命令，该目录的use指令会从go.work文件里自动移除。(注意：自动移除要从Go 1.18正式版本才会生效，Go 1.18beta1版本有bug，自动删除不会生效)

### go.work ###

go.work的语法和go.mod类似，包含如下3个指令：

*  go: go的版本，例如 go 1.18
 *  use: 添加一个本地磁盘上的Go Module到workspace的主Module集合里。use后面的参数是go.mod文件所在目录相对于workspace目录的相对路径，例如use ./main。use指令不会添加指定目录的子目录下的Go Module到workspace的主Module集合里。
 *  replace: 和go.mod里的 replace指令类似。go.work里的 replace指令可以替换某个Go Module的特定版本或者所有版本的内容。

## 使用场景和最佳实践 ##

Workspace使用起来很灵活，接下来会介绍最常见的几种使用场景及其最佳实践。

### 使用场景1 ###

给上游模块新增feature，然后在你的Module里使用这个新feature

为你的workspace(工作区)创建一个目录。Clone一份你要修改的上游模块的代码到本地。本地修改上游模块的代码，增加新的feature。  
在workspace目录运行命令go work init \[path-to-upstream-mod-dir\]。为了使用上游模块的新feature，修改你自己的Go Module代码。  
在workspace目录运行命令 go work use \[path-to-your-module\] 。go work use 命令会添加你的Go Module的路径到 go.work 文件里：

go 1.18
    
    use (
    ./path-to-upstream-mod-dir
    ./path-to-your-module
    )

运行和测试你的Go Module。发布上游模块的新feature。发布你自己的Go Module代码。

### 使用场景2：同一个代码仓库里有多个互相依赖的Go Module ###

当我们在同一个代码仓库里开发多个互相依赖的Go Module时，我们可以使用go.work，而不是在go.mod里使用replace指令。

为你的workspace(工作区)创建一个目录。

Clone仓库里的代码到你本地。代码存放的位置不一定要放在工作区目录下，因为你可以在go.work里使用use指令来指定Module的相对路径。在工作区目录运行 `go work init [path-to-module-one] [path-to-module-two]` 命令。

示例: 你正在开发 example.com/x/tools/groundhog 这个Module，该Module依赖 example.com/x/tools 下的其它Module。你Clone仓库里的代码到你本地，然后在工作区目录运行命令 `go work init tools tools/groundhog` 。  
go.work 文件里的内容如下所示：

go 1.18
    
    use (
    ./tools
    ./tools/groundhog
    )

tools路径下其它Module的本地代码修改都会被 tools/groundhog 直接使用到。

### 使用场景3：切换依赖配置 ###

如果要测试你开发的代码在不同的本地依赖配置下的场景，你有2种选择：

创建多个workspace，每个workspace使用各自的go.work文件，每个go.work里指定一个版本的路径。

创建一个workspace，在go.work里注释掉你不想要的use指令。

对于创建多个workspace的方案：

为每个workspace创建独立的目录。比如你开发的代码依赖了example.com/util这个Go Module，但是想测试example.com/util2个版本的区别，你可以创建2个workspace目录。  
在各自的workspace目录运行 go work init 来初始化workspace。在各自的workspace目录运行 go work use \[path-to-dependency\]来添加依赖的Go Module特定版本的目录。在各自的workspace目录运行 go run \[path-to-your-module\] 来测试go.work里指定的依赖版本。

对于使用同一个workspace的方案，可以直接编辑go.work文件，修改use指令后面的目录地址即可。

## 实战操作 ##

上述官网的搬运完毕，下面记录下我的操作

我的目录结构

cmd目录存放main.go函数，internal目录存放核心程序  
![在这里插入图片描述][0044ec57237949a4b2c663f38e9350c3.png]  
![在这里插入图片描述][d4fa48bc7cc24f0794f7ae3c53588cc8.png]

开始之前说明一下的我的go env  
![在这里插入图片描述][796da2bd81aa4a149a991328f51cc5b3.png]

因为要用到mod，所以GO111MPDULE要保证开启

### 1 package name ###

![在这里插入图片描述][e1eeb86bcbfa4730b2c418949b4c7d34.png]  
首先第一步的操作，需要统一`internal`目录下的`package`名称

这里将internal划分在名叫`internal`的`package`包里面，每个子文件都定义为

package postmaninternal

![在这里插入图片描述][c6be051b669240ef91185312be658b00.png]

### 2 go mod init \* ###

第二步，在`internal`目录下，创建mod文件，只需要创建即可，不需要一定要再执行go get

go mod init internal

运行命令，创建mod，名叫`internal`，这个`internal`是`internal`文件夹包的名称，也是与外界交流的名称

### 3 go work init \[path-to-module-one\] \[path-to-module-two\] ###

对`internal`目录的操作结束了，下面是cmd目录的操作

保险起见，cmd目录也进行一个go mod操作

go mod init postmancmd

生成一个mod，叫做`postmancmd`，名称其实无所谓。

接下来是正题，执行go work init

go work init ./ ../internal

创建并添加cmd目录和`internal`目录到`go.work`中，这里的`internal`指的是目录路径，通过`../internal`路径找到mod文件，得到当前文件夹的`package`名字叫做`internal`

go 1.19
    
    use (
    	.
    	../internal
    )

可继续在go.work中添加包路径，也可通过指令添加

go work use  [-r] moddir

### 4 main调用 ###

设置完成后，在main.go里面调用包即可通过如下方式

import (
    	"postmaninternal"
    )

或

import (
    	postmaninternal "postmaninternal"
    )

`postmaninternal "postmaninternal"`前面的`postmaninternal`其实是类似于全局变量，给`"postmaninternal"`包起个在当前文件内的别称，类似与一个局部变量或者结构体什么的，可有可无，看个人习惯  
![在这里插入图片描述][adc7390bba6342e4b03a0c54abf0e031.png]

### 5 replace ###

如果我要替换我的包，应该怎么弄呢？

很简单，通过如下操作实现  
![在这里插入图片描述][f086313f7fde4e578225b530b921fe4b.png]  
这步其实也验证了如何在自己发布包到GitHub上时，如何方便切换本地和远程的调试包版本的问题。

### 总结 ###

go work文件只存在于main函数在的目录位置

需要调用的package包，其package包目录生成mod文件（仅需要`go mod init *`生成即可）

work文件在上述应用场景中主要适用于本地调试和使用，如果要发布，提供给别人使用，建议通过replace的操作将文件位置替换为github位置（该位置目录下需有mod文件）

完结撒花！

[e1eeb86bcbfa4730b2c418949b4c7d34.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/1be89cfc901b46b9bd95a5b865ea0702.png
[5f97f50a03d44c9bb1786bbcdd6ff530.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/43b5c6feaa7148038137f50f12cc99cc.png
[0044ec57237949a4b2c663f38e9350c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/91925c9e689f437dac26ab27640fda93.png
[d4fa48bc7cc24f0794f7ae3c53588cc8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/08ec1d674d74421e87c39aa7b70cd0b1.png
[796da2bd81aa4a149a991328f51cc5b3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/dd330b99bc0e4827a4d3486db6e13d5f.png
[c6be051b669240ef91185312be658b00.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/5a294733a2b44e49935fb21d2772bce4.png
[adc7390bba6342e4b03a0c54abf0e031.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/28f3f03c92364bfaa2d68bb02d1a2e70.png
[f086313f7fde4e578225b530b921fe4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/a8ea172b3f9c4f30980e92770d6e940c.png