go.work 文件非必需，但多模块本地开发时可避免 GOPATH 和 go.mod 冲突；它是 Go 1.18 引入的工作区配置文件，仅作用于本地 go 命令流程，不替代 go.mod，也不影响构建产物。

go.work 文件不是必须的，但多模块协作时它能绕过 GOPATH 和 go.mod 冲突

Go 1.18 引入 go.work，本质是工作区（workspace）的配置文件，用于在本地同时开发多个 module 且不希望每次改一个就 go mod edit -replace。它不替代 go.mod，也不影响最终构建产物，只作用于 go 命令的本地开发流程。

典型适用场景：你正在改 github.com/org/lib，同时调试依赖它的 github.com/org/app；或者想把尚未发布到远端的内部模块直接挂载进主项目。

• 没有 go.work 时，只能靠 go mod replace 临时指向本地路径，但每次切换分支或清理 go.mod 容易丢配置
• go.work 是 workspace 级别控制，对所有子目录下的 go 命令生效（go build、go test、go list 等）
• 它只在本地生效，不会被 go mod tidy 修改，也不会上传到版本库（建议加进 .gitignore）

用 go work init + go work use 快速建立多模块链接

假设你有三个本地目录：~/dev/mylib（含 go.mod）、~/dev/myapp（也含 go.mod）、~/dev/shared（另一个 module）。你想让 myapp 在开发时直接使用本地 mylib 和 shared，而不是拉取远程版本。

操作步骤很简单：

• cd 到任一 module 根目录（比如 ~/dev/myapp），运行 go work init → 生成空 go.work
• 再依次执行：
  go work use ./../mylib
go work use ./../shared
• 此时 go.work 内容类似：

go 1.22

use (
	./../mylib
	./../shared
)

后续在 myapp 目录下执行 go run . 或 go test ./...，Go 工具链会自动识别并加载这两个本地 module，跳过它们的远程版本解析。

go.work 中的 replace 和 use 混用容易导致依赖解析失败

go.work 支持 replace 子句（类似 go.mod 里的语法），但它和 use 的优先级不同，且不能跨层级覆盖 —— 这是实际踩坑最多的地方。

• use 只接受相对路径（从 go.work 所在目录起算），且路径下必须存在有效的 go.mod
• replace 在 go.work 中仅用于“重定向远程 module 到本地路径”，例如：replace example.com/old => ./local-old，但它不会自动触发 use
• 如果某个 module 同时被 use 和 replace 声明，Go 会报错：cannot use replaced module ... in workspace
• 更隐蔽的问题：子目录里有独立 go.mod，但未被 use，此时 go 命令可能仍去拉远程版本，尤其在 go test ./... 遍历时

IDE 和 go test 的行为差异：VS Code Go 插件默认读取 go.work，但 goland 需手动启用

VS Code 的 Go 插件（v0.34+）默认识别 go.work 并据此提供跳转、补全和诊断；但 Goland 默认忽略它，需手动开启：

• Goland 设置 → Languages & Frameworks → Go → Go Modules → 勾选 Enable Go workspaces
• 终端中 go test 能正常走 go.work，但某些 CI 脚本若显式指定 GOPATH 或清空环境变量，会导致 go.work 失效
• 运行 go list -m all 可验证当前生效的 module 列表：被 use 的本地路径会显示为 module-name v0.0.0-00010101000000-000000000000 这类伪版本，而非远程 tag

真正麻烦的是嵌套 module 场景：比如 myapp/go.mod 依赖 mylib，而 mylib/go.mod 又依赖 shared，但你只在 go.work 里 use 了 myapp 和 shared，漏了 mylib —— 此时 mylib 仍会尝试拉远程 shared，造成版本不一致。