go build 报“module xxx is not in main module”是因为 go work 仅影响工作区上下文，不改变子模块自身 go.mod 的依赖解析；须在 go.work 目录执行命令，并确保 use 路径正确、无冲突 replace。
go work 模式开启后 go build 为什么还报 “module xxx is not in main module”
因为 go work 只影响当前工作区的模块解析上下文，不改变单个模块内部的 go.mod 依赖声明。如果你在某个子模块里执行 go build，Go 仍会按该模块自身的 go.mod 查找依赖——而它并不知道其他模块已通过 go work 加入工作区。
实操建议：
- 统一在工作区根目录（即含
go.work文件的目录）下运行go build或go run，不要 cd 进子模块再执行 - 确认
go.work文件中已用use ./xxx显式包含所有要联动开发的模块路径 - 检查子模块的
go.mod是否仍硬编码了旧版本号（比如require example.com/lib v0.1.0），应改为replace或直接删掉——工作区模式下，本地模块优先被直接加载，无需require版本
多个本地模块互相引用时，replace 和 go work use 到底该选哪个
replace 写在单个 go.mod 里，只对那个模块生效；go work use 是全局工作区指令，对所有加入的模块都生效，且优先级更高。开发阶段强烈推荐后者。
原因很实际：当你改了模块 A，又立刻在模块 B 里测试调用，如果 B 用 replace 指向 A 的本地路径，那每次 A 的路径稍有变动（比如重命名、挪目录），B 就得同步改 go.mod；而 go work use ./a 是相对工作区根的静态路径，只要结构不变，就一直有效。
注意点：
-
go work use路径必须是相对于go.work所在目录的，不能用绝对路径或../ - 如果某个模块已被
replace覆盖，它仍会优先生效——此时需手动删掉replace行，否则工作区模式不接管 -
go work use不支持通配符，每个模块都要显式列出
CI/CD 流水线里能不能用 go work 模式
不能直接用。标准 Go 工具链（包括 go test、go list 等）在非工作区模式下完全无视 go.work 文件；CI 环境通常也不预设工作区上下文。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
这意味着：本地能跑通的 go work 多模块构建，在 CI 上大概率失败，报错类似 no required module provides package xxx。
可行做法：
- CI 中退回到单模块视角：每个模块独立
go mod tidy && go test，用replace或私有代理指向其他模块的发布版本 - 若必须验证跨模块集成，可在 CI 中临时生成
go.work并运行go work sync && go test ./...，但需确保所有模块代码已 checkout 到对应 commit - 避免在
go.work中使用未提交的本地修改——CI 拉的是 clean repo，不存在“未暂存文件”
vscode-go 插件对 go work 的支持现状
较新版本（v0.14+）基本支持，但有个关键限制：插件只会读取打开窗口根目录下的 go.work，不会自动向上查找父目录。如果你在子模块目录里开 VS Code，即使上层有 go.work，插件也当它不存在。
结果就是：跳转定义失效、类型提示不准、go fmt 报错找不到依赖。
解决办法很简单：
- 始终在
go.work所在目录启动 VS Code：code . - 确认 VS Code 状态栏右下角显示 “Workspace: xxx (go.work)” 而不是 “Module: yyy (go.mod)”
- 如果用了多根工作区（multi-root workspace），确保
go.work所在文件夹是第一个 root，否则插件可能选错上下文
工作区模式不是“一劳永逸”的模块管理开关，它只在你明确控制入口点、路径结构和工具链行为时才稳定。最常出问题的地方，其实是开发者误以为 go work 会自动透传到子命令或外部工具里——它不会。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
