答案：必须在go.work所在根目录执行命令，且确保go.work中use路径显式列出、无残留replace。go build报“module xxx is not in main module”是因为误入子模块目录执行，此时工作区模式不生效；需删掉各子模块go.mod中的require行或replace，改由go work use全局接管。
直接在工作区根目录下执行命令，且确保 go.work 中的 use 路径全部显式列出、无残留 replace，否则本地模块不会被识别。
go build 报 “module xxx is not in main module” 怎么办
这不是模块没加进工作区，而是你在子模块目录里单独执行了 go build。Go 工具链只在含 go.work 的目录下才启用工作区模式；一旦 cd 进 service_a/ 再运行命令，它就退回到单模块上下文，完全无视 go.work。
- 必须始终在
go.work所在目录（即工作区根）执行go build、go run、go test -
go.work文件里得有对应模块的use ./service_a和use ./lib_b，路径必须是相对根目录的，不能带../或绝对路径 - 检查各子模块的
go.mod：如果还留着类似require example.com/lib v0.1.0的行，要么删掉，要么改成replace—— 但更推荐删掉，让工作区模式直接接管本地加载
replace 和 go work use 哪个该用
开发阶段一律优先用 go work use，replace 只适合临时绕过某依赖或调试远程模块。
-
replace写在某个go.mod里，只对该模块生效；改路径就得同步改多处，容易漏 -
go work use ./lib_b是全局声明，所有模块都按这个路径解析lib_b，只要目录结构不动，就一直有效 - 注意冲突：如果某个模块的
go.mod里已有replace指向同名模块，它会优先生效，go work use不会覆盖 —— 必须手动删掉那行replace
CI/CD 流水线里能用 go work 吗
不能直接用。标准 Go 工具链在非工作区上下文中完全忽略 go.work 文件，CI 环境默认不激活工作区模式。
- CI 构建时，应还原为单模块行为：每个子模块独立
go mod download+go build，依赖走远程版本 - 若需测试多模块集成，可在 CI 中临时生成
go.work并执行go work init+go work use，但必须确保所有模块路径可被正确解析，且不依赖本地未提交的变更 - 真正要上线的构建产物，永远基于
go.mod中声明的版本，而非工作区里的本地路径
最易被忽略的是：工作区模式只影响开发时的本地命令执行，它不改变模块本身的依赖声明，也不参与最终发布逻辑。你改了 lib_b 的代码，service_a 能立刻用上，但别人 go get 时拿不到你的修改 —— 那部分仍由 go.mod 的 require 版本决定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
