因为在子模块目录执行go build时，Go工具链只读取该模块自身的go.mod，完全忽略上层go.work文件，导致无法识别工作区中其他模块，从而报“module xxx is not in main module”错误。
go work 模式不是“开了就自动生效”的开关，它只在含 go.work 的目录下、且命令由 Go 工具链原生支持时才起作用；子模块里直接 go build 一定会报错。
为什么在子模块里执行 go build 会报 “module xxx is not in main module”
Go 工具链在子模块路径下运行时，只读取该模块自身的 go.mod，完全无视上层的 go.work 文件。即使你已用 go work use ./lib_b 把模块加进工作区，只要 cd lib_b && go build，Go 就仍按 lib_b/go.mod 里的 require 去找依赖——而那个版本号很可能早已过时或指向远程 tag。
常见错误现象：
- 改了
lib_b的代码，service_a调用时却没生效 -
go list -m all显示依赖仍是example.com/lib_b v0.1.0，而非本地路径 -
go run main.go报错：cannot load example.com/lib_b: module example.com/lib_b@v0.1.0 (from $GOROOT/src/example.com/lib_b): not found
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有构建、运行、测试命令必须在
go.work所在目录（即工作区根）执行 - 删掉子模块
go.mod中对自身或其他本地模块的require行（如require example.com/lib_b v0.1.0），工作区模式下不需要它们 - 确认
go.work里use的路径是相对工作区根的，比如use ./service_a ./lib_b，不能写成use ../lib_b或绝对路径
replace 和 go work use 到底该用哪个
replace 是模块级补丁，go work use 是工作区级声明；开发阶段后者更稳、更少维护成本。
使用场景：
- 你正在同时改
lib_b和service_a，且希望每次service_a编译都用最新lib_b源码 —— 选go work use - 你只想临时让某个模块绕过远程依赖，但不涉及多模块联动 —— 可用
replace
关键差异：
-
replace写在go.mod里，会被go mod tidy误删或覆盖；go work use独立存在，不受模块操作影响 -
replace路径若变更（比如把lib_b改名成lib-core），所有引用它的go.mod都得手动改；go work use只需改一次go.work - 如果某模块
go.mod里已有replace example.com/lib_b => ./local-lib，那go work use会被跳过——必须先删掉这行replace
CI/CD 流水线里能不能用 go work 模式
不能直接用。标准 Go 工具链在非工作区上下文（即没检测到 go.work 或未在对应目录执行）下，会彻底忽略 go.work 文件。
这意味着：
-
go test ./...在 CI runner 的任意路径下运行，都不会加载工作区逻辑 - Docker 构建中若
COPY了go.work但没WORKDIR到它所在目录，go build依然走默认模块解析 - GitHub Actions 或 GitLab CI 中，必须显式
cd /workspace-root && go build，且确保go.work存在
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- CI 脚本开头加
ls -l go.work || exit 1，防止文件遗漏 - 避免在 CI 中依赖工作区模式做依赖注入；对外发布的模块应通过
go mod edit -replace或发布正式版本来解耦 - 本地开发用
go work，CI 构建用单模块 + 显式go mod download+go build -mod=readonly更可靠
真正容易被忽略的一点：工作区模式不改变 go.mod 文件语义，它只是给 Go 工具链加了一层“查找优先级”。一旦你离开工作区上下文，或者某个工具（比如旧版 IDE 插件、自定义脚本）没调用 go list -m 而是直接解析 go.mod，行为就会回退到模块原始声明——这不是 bug，是设计使然。
