3. Go工作区模式与多模块协作
在 Go 1.18 之前，多模块协作是一件相当别扭的事：如果 A 模块依赖 B 模块，而 B 还在本地开发中，你只能靠 replace 指令把 B 指向本地路径，或者干脆把 B 的代码复制进 A。前者需要手工维护 go.mod，后者则彻底破坏了模块边界。Go 1.18 引入的 工作区模式（Workspace Mode）用一个 go.work 文件把多个本地模块临时“编组”在一起，让它们在不修改各自 go.mod 的前提下互相引用，这正是本地多模块联调最需要的机制。
go.work 文件的结构与三个核心命令
go.work 本身是一个很小的文件，它由 go 版本声明、use 指令和可选的 replace 指令组成。use 列出参与工作区的模块目录，replace 则用于把某个依赖重定向到工作区外的路径。三个命令各司其职：
go work init：在当前目录创建go.work，可同时带上若干模块路径作为初始use项。go work use：向已有go.work追加或移除模块目录，是日常增删模块的主要手段。go work sync：把工作区中各模块的依赖版本“对齐”回各自的go.mod，让工作区里实际生效的版本被固化下来。
一个典型的多模块仓库结构如下：服务模块 svc 依赖公共库 lib，两者都在本地。执行 go work init ./svc ./lib 后，go.work 内容大致为：
go 1.22
use (
./svc
./lib
)
此时在仓库根目录运行 go build ./... 或 go test ./...，Go 会优先使用工作区中 use 的本地模块，而不是去模块代理下载 lib 的某个发布版本。这一点非常关键：工作区只影响本地构建，不会改变 go.mod 中声明的依赖版本，因此不会污染发布产物。
本地多模块联调的实际操作
假设 lib 新增了一个函数 FormatID，svc 想立刻调用它验证效果。没有工作区时，你需要先在 svc/go.mod 里加 replace example.com/lib => ../lib，联调完再删掉，稍不留神就会把 replace 提交上去。有了工作区，流程变成：
- 在仓库根目录执行
go work init ./svc ./lib（首次）。 - 在
lib中修改代码并保存。 - 在根目录执行
go test ./svc/...，测试会直接编译本地lib。 - 联调完成后，若希望把工作区里验证过的版本固化进
svc/go.mod，执行go work sync。
这里有一个容易踩的坑：go.work 是开发者本地文件，通常不应提交到版本库（建议加入 .gitignore），否则会强制所有协作者使用相同的本地路径布局。团队若确实需要共享工作区配置，应通过文档或脚本生成，而不是直接提交。
另一个常见问题是版本冲突。当 svc 的 go.mod 要求 lib v1.2.0，而工作区里 use 的本地 lib 版本号是 v1.3.0 时，工作区会以本地代码为准，但 go work sync 会把 svc/go.mod 中的 lib 版本提升到 v1.3.0。如果 lib 尚未发布 v1.3.0，同步后 svc 单独构建就会失败。因此 go work sync 应在确认依赖版本已发布后再执行，或仅在本地临时使用。
monorepo 与 polyrepo 的组织策略
工作区模式解决的是“本地怎么联调”，而 monorepo 与 polyrepo 解决的是“代码长期放在哪里”。两者不是互斥的，而是不同规模与协作模式下的取舍。
monorepo（单仓库多模块）把多个模块放在同一个 Git 仓库中，例如 /repo/svc、/repo/lib、/repo/tools。它的优势是原子提交：修改 lib 接口的同时可以一并修改 svc 的调用点，CI 一次跑完所有模块的测试，版本天然一致。代价是仓库体积增长、CI 时间变长、权限粒度粗。适合团队规模中等、模块间耦合较紧、发布节奏统一的场景。在 monorepo 中，go.work 几乎是标配，开发者克隆仓库后执行一次 go work init ./... 即可获得完整的本地联调能力。
polyrepo（多仓库单模块）让每个模块独立成库、独立版本、独立发布。它的优势是边界清晰、权限可控、CI 快、发布独立。代价是跨模块修改需要“先发 lib 新版本，再升级 svc 依赖”，联调链路长。适合模块间接口稳定、团队自治度高、发布节奏差异大的场景。在 polyrepo 中，工作区模式依然是本地联调的利器：开发者把 lib 和 svc 克隆到相邻目录，用 go work init ../lib . 临时编组，联调完删除 go.work 即可，完全不触碰两个仓库的 go.mod。
| 维度 | monorepo | polyrepo |
|---|---|---|
| 代码位置 | 同一仓库多模块 | 每模块独立仓库 |
| 跨模块修改 | 一次提交完成 | 需先发布再升级 |
| 版本一致性 | 天然一致 | 需显式对齐 |
| CI 成本 | 较高，需增量构建 | 较低，按仓库触发 |
| go.work 角色 | 长期存在，日常依赖 | 临时创建，联调用完即删 |
| 适用场景 | 耦合紧、节奏统一 | 接口稳、自治度高 |
go.work 加入 .gitignore，同时提供一个 make work 或脚本自动执行 go work init ./...，让新成员一条命令完成环境准备。在 polyrepo 中，可以把常用的联调组合写成一个本地脚本，例如 go work init ../lib ../shared .，避免每次手工敲路径。
go.work 中的 use 路径是相对于 go.work 所在目录的。如果把 go.work 放在仓库根目录，而模块在子目录，路径应写成 ./svc 而非 svc。另外，工作区模式下 go mod tidy 的行为会受工作区影响，建议在退出工作区（删除或重命名 go.work）后再对单个模块执行 go mod tidy，以免把工作区中的临时版本写入 go.mod。
总结来说，go.work 是本地多模块联调的“临时编组器”，它让 monorepo 的日常开发更顺滑，也让 polyrepo 的跨仓库联调不再需要污染 go.mod。选择 monorepo 还是 polyrepo，取决于团队规模、模块耦合度与发布节奏；而无论选哪种，工作区模式都能在不改变仓库结构的前提下，显著降低本地联调的成本。