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，而不是拉取远程版本。
操作步骤很简单：
立即学习“go语言免费学习笔记（深入）”；
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
- cd 到任一 module 根目录（比如
~/dev/myapp），运行go work init→ 生成空go.work - 再依次执行：
go work use ./../mylibgo 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，造成版本不一致。
