最近在项目开发中使用了下 go 1.18 的 workspace 新特性，有一些实操的感受分享给大家。正好最近的 goland 2022.3 也同步支持了 workspace 特性，所以这也激发了我在项目开发中想尝试尝试。
1. 使用场景
workspace 经常用于：当你有一个项目依赖另一个项目（比如一个公共库），而且这个公共库也需要你同步开发的时，那么 workspace 方才凸显的它作用。
如果说你使用的依赖库都是由别的同学来协助完成，那么其实你多半用不上 worksapce，这样的话，你唯独要做的就是和那些写库的同学搞好关系就行，当你阅读到本段时也就应该就此打住。
恰好，不是所有的开发RD都是那么幸运（比如说我），为了提高开发效率，我们经常把项目常用的类库或者api封装为公共服务，供其他项目使用，一个项目依赖另一个项目是家常便饭，而且还需要同步开发测试。
但开发完公共库，你肯定需要做些本地测试，在 workspace 未出来之前，我们常用的就是go.mod 文件中的 replace 指令：
replace (
github.com/ntt360/errors v0.9.3 => /Users/xxx/projects/errors
)
讲真话是，replace 指令其实我们用的也挺开心的，只是我们得格外的小心，生怕这个行代码被提交到版本库，其他同学运行就GG了。所以这也是 workspace 的优势，**它不需要修改 go.mod文件 **。
对于 workspace 使用方法这里不再展开，有兴趣的同学可以自行研究，从上面这一点来说，workspace 的概念确实比 replace 指令要优秀。
2. 参与workspace的项目非必须是当前目录
workspace 并不要求参与的项目都必须放在当前目录下，依赖项目放在别处也是没有任何问题的，拿下面的demo举例来说：
workspace
├── errors/
├── example/
└── go.work
上面的 example 是我们的业务项目，errors 是我们维护的一个公共包项目，在 go.work 中我们配置了这俩项目的依赖：
go 1.19
use (
./errors
./example
)
这样，example 项目就依赖着本地的errors项目目录。但我要强调的是，这并非是必需的。errors 项目完全可以放在其他位置，我们要做的也仅仅是在 go.work 里配置依赖的项目路径即可，比如：
# 项目在不同目录
/projects/
├── errors/
└── workspace
├── example/
└── go.work
example 依赖 errors，但 errors 不在同一个目录，这时候我们需要注意 go.work 里面的引入路径：
go 1.19
use (
./../errors
./example
)
上面的这样，我们运行 example 项目也绝对没问题，而且也符合我们实际开发场景。
3. go.work 依赖顺序没关系
我们发觉在 go.work 配置 use 指令里会把依赖和被用来的包都放进去，那么谁先谁后有关系吗？ 答案是无疑的，没有任何关系。
use (
./../errors
./example
)
// 或
use (
./example
./../errors
)
上面两种 use 指令都能正确运行，而且像类似 goland 的IDE会自动帮我们维护这个文件，一般不需要我们手动配置。
4. 记得清理workspace
当我们使用 workspace 完成公共库测试后，我们会发一个新的版本，这时候如果你想使用远程仓库实际的版本，而不是本地磁盘的版本。那么记得清理workspace配置！！
