报错“module xxx is not in main module”是因为在错误目录执行命令，必须在go.work所在根目录运行go build；需检查go.work中use路径是否正确、删除子模块go.mod中冗余require、移除冲突replace，并确保go111module=on。
go build 报 “module xxx is not in main module” 怎么办
这不是模块没加进工作区，而是你在错误目录执行了命令。Go 工作区模式（go.work）只在含该文件的目录及其子目录生效，且仅影响模块解析上下文，不改变子模块自身 go.mod 的依赖声明逻辑。
- 必须在
go.work所在目录（即工作区根目录）下运行go build或go run，不能cd进某个子模块再执行 - 检查
go.work文件里是否用use ./xxx显式列出了所有要联动的模块路径，路径必须是相对工作区根的，不能带../或绝对路径 - 子模块的
go.mod中若还留着硬编码的require example.com/lib v0.1.0，得删掉——工作区模式下本地模块直读，不需要 require 版本
多个本地模块互相引用，该用 replace 还是 go work use
开发阶段优先选 go work use。它作用于整个工作区，路径稳定、维护成本低；而 replace 写在单个 go.mod 里，只对该模块生效，且一旦模块路径变动（比如重命名或挪目录），所有引用它的 go.mod 都得手动同步改 replace 行。
-
go work use路径必须相对于go.work目录，例如use ./auth-service，不是use ../auth-service - 如果某个模块已被
replace覆盖，它会优先生效，导致工作区模式不接管——此时必须手动删掉对应replace行 - 提交前无需清理
go.work，但建议 gitignore 掉它，避免 CI 环境误用（CI 通常不走工作区模式）
为什么 go mod init 后 go build 还报 “cannot find module providing package”
根本原因是当前工作目录不在任何模块根下。Go Modules 只认 go.mod 所在目录及其子目录为有效作用域，其他位置执行命令就等于“没模块”。
- 先
cd到你放main.go的空目录，再运行go mod init myapp；不要在cmd/或src/子目录里 init - 确认
GO111MODULE=on（运行go env -w GO111MODULE=on），否则即使有go.mod也可能 fallback 到 GOPATH 模式 - 如果项目已有代码但没
go.mod，回到最外层项目目录再 init，别在任意子目录操作
联合编译多个 main 包时 go build 失败
Go 不允许模糊入口：当项目里有多个 cmd/xxx/main.go，直接 go build 会报 no Go files in current directory 或构建出错，因为它不知道该编译哪个。
- 必须显式指定目标，例如
go build -o bin/api cmd/api/main.go - 如果想一次构建全部，可用 shell 循环：
for d in cmd/*; do go build -o "bin/$(basename $d)" "$d/main.go"; done - 注意
go.work模式下仍需指定具体.go文件路径，不能只写目录名
go.work 的路径声明、以及各子模块 go.mod 是否干净——任何残留的 replace 或旧 require 都可能让 Go 绕过工作区，退回单模块视角。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
