work 多 Module 工作区模式

Go 工程时，总会遇到 2 个经典问题，特别的折腾人。

如下：

依赖本地 replace module。
依赖本地未发布的 module。
第一个场景：像是平时在 Go 工程中，我们为了解决一些本地依赖，或是定制化代码。会在 go.mod 文件中使用 replace 做替换。

如下代码：

replace golang.org/x/net => /Users/eddycjy/go/awesomeProject

问题就在这里：

本地路径：所设定的 replace 本质上转换的是本地的路径，也就是每个人都不一样。
仓库依赖：文件修改是会上传到 Git 仓库的，不小心传上去了，影响到其他开发同学，又或是每次上传都得重新改回去。
未发布的 module
第二个场景：在做本地的 Go 项目开发时，可能会在本地同时开发多个库（项目库、工具库、第三方库）等。

增加了 go work 工作区的概念，针对的是 Go Module 的依赖管理模式。

其能够在本地项目的 go.work 文件中，通过设置一系列依赖的模块本地路径，再将路径下的模块组成一个当前的工作区，他的读取优先级是最高的。

只要执行 go work init 就可以初始化一个新的工作区，后面跟的参数就是要生成的具体子模块 mod。

命令如下：

go work init ./mod ./tools

awesomeProject
├── mod
│ ├── go.mod // 子模块
│ └── main.go
├── go.work // 工作区
└── tools
├── fish.go
└── go.mod // 子模块

生成的 go.work 文件内容：

go 1.18

use (
./mod
./tools
)

新的 go.work 与 go.mod 语法一致，也可以使用 replace 语法：

go.work 文件内共支持三个指令：

go：声明 go 版本号，主要用于后续新语义的版本控制。
use：声明应用所依赖模块的具体文件路径，路径可以是绝对路径或相对路径，可以在应用命目录外均可。
replace：声明替换某个模块依赖的导入路径，优先级高级 go.mod 中的 replace 指令。
若想要禁用工作区模式，可以通过 -workfile=off 指令来指定。

也就是在运行时执行如下命令：

go run -workfile=off main.go

go build -workfile=off

go.work 文件是不需要提交到 Git 仓库上的，否则就比较折腾了。

只要你在 Go 项目中设置了 go.work 文件，那么在运行和编译时就会进入到工作区模式，会优先以工作区的配置为最高优先级，来适配本地开发的诉求。

https://segmentfault.com/a/1190000041331153
https://stackoverflow.com/questions/70482508/grpc-withinsecure-is-deprecated-use-insecure-newcredentials-instead/70482635