“module xxx is not in main module”错误主因是工作区未生效，须在含go.work的根目录执行命令，确保use路径为相对路径、无冲突replace，且ide正确识别工作区上下文。
go build 报 “module xxx is not in main module” 怎么办
这不是模块写错了，是工作区根本没生效。Go 工具链只在含 go.work 的目录下才识别工作区，进子目录就退化成单模块模式。
- 用
ls go.work确认当前目录就是工作区根目录，不是某个./api或./cmd/app子目录 - 所有命令（
go build、go test、go mod tidy）必须在该根目录下执行，不能cd进去再跑 -
go.work里的use路径必须是相对路径，比如./lib，不能写/full/path/lib或../other/lib - 删掉各子模块
go.mod里残留的replace行——它会优先于go work use生效，导致本地改动不被加载
VS Code / GoLand 里 import 不补全、跳转失效
根本不是插件没装，是编辑器打开的“工作区”和 go.work 对不上。gopls 启动时找不到工作区上下文，直接降级为 GOPATH 模式。
- VS Code 别用 “Open Folder” 打整个仓库顶层；改用 “Add Folder to Workspace…” 逐个添加子模块目录，再在设置里加
"go.toolsEnvVars": { "GOFLAGS": "-mod=mod" } - GoLand 右键点击含
go.work的目录 → “Mark Directory as → Go Module Root”，不是点子模块目录 - 执行命令面板里的 “Go: Toggle Logs”，看 gopls 启动日志里
working directory是不是你go.work所在路径 - 刚装完
gopls或改过PATH，必须重启 VS Code —— 插件进程不热加载环境变量
CI 流水线里 go test 失败，报 no required module provides package xxx
这不是配置错，是预期行为。CI 环境默认不读 go.work，工具链压根无视它。
-
go.work是纯本地开发机制，仅影响你本机 shell 的go命令行为 - CI 中应还原为单模块模式：把各子模块单独发布版本，主模块用
require声明依赖，或用go mod edit -replace注入本地路径（需配合git clone子模块到对应位置） - 别在 CI 脚本里写
go work use—— 它不生效，还可能干扰缓存
go version 和 go.mod 声明版本冲突
错误信息 go: cannot use go 1.21.6 with go 1.22 mod 不是环境没装，是当前 shell 的 Go 版本和 go.mod 里 go 1.22 不匹配。
- 运行
go version和go env GOROOT，确认输出的版本和路径是你想用的那个 - 用
gvm use go1.22.3切换（推荐），或手动设GOROOT=/path/to/go1.22.3+PATH=$GOROOT/bin:$PATH - 检查 shell 配置文件（
~/.zshrc等）是否有多条export PATH，旧版 Go 路径可能排在前面，导致which go和go version对不上
go.work 文件存在 ≠ 工作区已激活，必须满足目录、路径、环境三者同时对齐。任何一环断开，Go 就当它不存在。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
