必须在go.work所在根目录执行go build，不能进入子模块目录；同时需清理子模块go.mod中冲突的replace语句，并确保use路径为相对路径且有效。
go build 报 “module xxx is not in main module” 怎么办
这不是模块没加进工作区，而是你在错误的位置执行了命令。Go 工具链只在 go.work 所在目录及其子目录下识别工作区上下文——但关键在于：必须在该目录下运行 go build，不能 cd 进某个子模块再执行。
常见错误现象：
- 在
./service-a目录里跑go build，报错说module github.com/myorg/lib不在主模块中 -
go.work里明明写了use ./lib，但go list -m all仍只显示当前模块
实操建议：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 始终在
go.work文件所在目录（即工作区根目录）执行go build、go run、go test - 确认
go.work中的路径是相对路径，且能被正确解析：比如use ./lib要求./lib/go.mod存在，不能是use ../lib或绝对路径 - 运行
go work edit -json查看当前生效的模块列表，比肉眼检查更可靠
replace 和 go work use 冲突时谁生效
replace 优先级高于 go work use，只要子模块的 go.mod 里还留着 replace 行，工作区模式就不会接管那个依赖。
立即学习“go语言免费学习笔记（深入）”；
这会导致你改了 ./lib，但 ./app 仍然用旧代码——因为 ./app/go.mod 里的 replace github.com/myorg/lib => ./lib 没删，Go 就绕过工作区，直接按这个硬编码路径加载。
实操建议：
- 启用工作区前，批量清理所有子模块
go.mod中的replace行（尤其是指向本地路径的） - 用
go work use替代replace：它作用于整个工作区，路径稳定、无需重复维护 - 如果某模块确实需要临时覆盖远程依赖（比如调试第三方库），可在工作区根目录下用
go work edit -replace=...，而非写进单个go.mod
IDE（如 VS Code / GoLand）不识别工作区怎么办
不是 IDE 坏了，是它默认只读取当前打开文件夹的 go.mod，没主动加载 go.work。VS Code 的 Go 扩展从 v0.38+ 开始支持，但需手动触发。
常见表现：
- 跳转定义卡在远程版本，不进本地
./lib源码 - 自动补全提示缺失，或提示“no package found”
- 状态栏显示 “Go: Loading…” 长时间不动
实操建议：
- VS Code：按
Ctrl+Shift+P→ 输入 “Go: Restart Language Server”，重启后会自动探测go.work - GoLand：File → Close Project → 重新打开工作区根目录（不是子模块目录），并在 Settings → Go → Gopath 中勾选 “Enable Go Workspaces”
- 验证是否生效：在任意
.go文件里import一个本地模块路径，看是否能正常解析并跳转
CI/CD 中要不要提交 go.work 文件
不要提交，也不要在 CI 中启用工作区模式。
原因很实际：工作区是纯本地开发机制，依赖路径硬编码、无版本约束、不兼容 GOPROXY 缓存。CI 环境拉代码时，go.work 里的 use ./lib 路径根本不存在，go build 直接失败。
实操建议：
-
go.work加入.gitignore，仅保留在开发者本地 - CI 构建时，每个模块应独立
go mod download && go build，靠go.mod中的require和版本号驱动 - 若需测试多模块集成，应在 CI 中先
go install本地模块到$HOME/go/bin，再让主模块通过replace引用（仅限 CI 阶段，非开发阶段）
工作区模式的边界非常清晰：它只解决「人坐在电脑前写代码时」的协同问题。一旦脱离这个场景，比如自动化构建、跨机器协作、发布归档，就得退回模块系统本身的语义——版本号、不可变性、远程可复现性。这点容易被忽略，但恰恰是它设计初衷所在。
