系列導讀：
1、Go 1.18 系列篇（一）：如何升級 Go 1.18 ？
2、Go 1.18 系列篇（二）：一文掌握泛型的使用
對我來說，Go1.18 最 "實用" 的功能，應該是 Go 工作區模式，雖然上篇文章中的泛型在某些場景下也是非常有用，但我還沒遇到泛型的使用場景，因此它不能為我帶來收益，而 Go 的工作區模式，則不一樣，它使得開發者在多個模塊中的開發工作變得更加簡單。
接下來來簡單介紹一下
1. 誕生背景
在介紹 工作區模式 （workspace mode）之前，先簡單地說一下工作區誕生的背景，只有了解了痛點之后，學習一個新的知識點，才更有動力。
我在 $GOPATH/src 目錄下創建 github.com/iswbm/demo 及 github.com/iswbm/util 兩個空的 go 包
然后分別使用 go mod init 來初始化
$ cd github.com/iswbm/demo
$ go mod init github.com/iswbm/demo
$ cd ../util
$ go mod init github.com/iswbm/util
並在 demo 中寫入 main.go，在 util 寫入 util.go ，內容如下
我們都知道，正常 Go 項目中引用的包，都需要在對應代碼托管網站上有該包，才能編譯及運行。
但如果 demo 引用 util 項目的包，而 util 本身也還在自己的本地上開發，並沒有上傳到 github，那么 demo 包在調試過程中肯定是無法找到 util 包的。
在沒有工作區的情況下（也即 Go 1.18 之前），可以通過在 go.mod 中使用 replace 來重定向
module github.com/iswbm/demo
go 1.17
require github.com/iswbm/util v1.0.0
replace github.com/iswbm/util => ../util
修改完 go.mod 后，運行正常輸出
可使用 replace 存在兩個問題：
- replace 本身編輯就比較麻煩，我一直是手動編輯的
- 開發完成后，還要記得將 replace 刪除，並執行 go mod tidy ，否則別人就無法使用
2. 工作區模式
Go 1.18 提供的工作區模式，就可以優雅的解決如上出現的問題。
上面我使用的是 go 1.17 初始化的項目，現在要用 go 1.18 的工作區模式，因此先將 go.mod 里的 go 版本改為 go 1.18，並都所有的依賴全部刪除。
然后退回到 $GOPATH/src 目錄，執行如下命令創建工作區文件 go.work
go18 work init github.com/iswbm/demo github.com/iswbm/util
創建的 go.work 文件如下所示
然后無論我在哪個目錄下，只要所在位置的父級目錄有 go.work 文件，即處於該工作區內，go 的編譯器都會自動引用本地的 util 包
3. 寫在最后
有了工作區模式，將使整個開發流程更加流暢，個人認為這可能是 go1.18 最為實用的功能，強烈推薦大家使用起來～
另外 go.work 文件是工作區的標志，該文件不用上傳至 github，只用於本地開發測試使用。