go work 模式仅在含 go.work 的根目录下生效，子模块中执行 go build 必报“module xxx is not in main module”；因工作区不修改子模块 go.mod 解析逻辑，且 replace 优先级高于 use，故须删 replace、用相对路径 use、并在根目录统一执行命令。
go work 模式不是“开了就能用”，它只在工作区根目录下生效，且对子模块的 go.mod 文件完全无感——你 cd 进子模块执行 go build，报错“module xxx is not in main module”是必然结果。
为什么 go build 在子模块里总报 “module xxx is not in main module”
因为 go work 只影响当前 shell 的工作区上下文，不修改任何 go.mod 的解析逻辑。子模块自身 go.mod 里如果还留着 require example.com/lib v0.1.0，Go 就会照常去拉远程版本；它根本不知道旁边有个同名本地模块已被 go work use 加进来了。
- 必须在含
go.work的目录下运行go build、go run、go test等命令 - 子模块的
go.mod中，所有被工作区覆盖的依赖项应删掉require行，或至少确保没配replace——否则replace优先级高于go work use，工作区直接被绕过 -
go.work中的路径必须是相对路径（如./lib_b），不能带../或绝对路径，也不能用通配符
go work use 和 replace 到底该用哪个
开发阶段无条件选 go work use。它作用于整个工作区，所有模块共享同一套本地路径映射，改一次路径，全局生效；而 replace 是写死在单个 go.mod 里的字符串替换，路径一挪就得手动改，还容易误提交到 Git。
-
replace是模块级补丁，适合临时调试某个特定依赖；go work use是工作区级契约，适合长期协作开发 - 如果某个模块已用
replace指向本地路径，又想切到工作区模式，得先手动删掉那行replace，否则工具链永远走replace分支 -
go work use ./a和go work use ./b之间没有隐式依赖顺序，但若a依赖b，而b没被use，则a仍会按自己go.mod去找b——所以所有相互引用的模块都得显式use
CI/CD 流水线里能不能直接跑 go work 命令
不能。标准 Go 工具链在非工作区上下文中完全忽略 go.work 文件，CI 环境默认就是这种状态。你 push 上去的 go.work 对 go test、go build 都无效。
- CI 脚本里要还原成传统模块行为：逐个进入子模块，用
go mod tidy+go build，或提前用go mod vendor锁定依赖 - 如果必须模拟工作区效果，可在 CI 中临时生成
go.work并用GOFLAGS=-mod=mod go build强制启用，但这属于 hack，稳定性差，不推荐 -
go.work文件本身应该提交进 Git（尤其路径稳定时），但它只是本地开发辅助，CI 不依赖它也能构建成功——这是设计前提
最易被忽略的一点：IDE（如 VS Code + Go extension）是否识别 go.work 完全取决于插件版本和配置。旧版可能只读 go.mod，导致跳转、补全失效，此时需检查 go.work 是否被正确加载，而不是怀疑代码写错了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
