必须在go.work所在工作区根目录执行命令，否则go build仍报“module xxx is not in main module”，因go仅在根目录识别工作区上下文，子模块内执行会退回到单模块模式，无视go.work；use路径须为相对于go.work的静态路径，且子模块go.mod中replace会优先劫持依赖解析。
必须在工作区根目录执行命令，否则go build仍会报“module xxx is not in main module”——这不是配置错了，是执行位置错了。
为什么go build还在报“module xxx is not in main module”
这个错误不是go.work没生效，而是你当前所在目录不对。Go 工具链只在含go.work的目录及其子目录下识别工作区上下文；但如果你cd进某个子模块再运行go build，它就退回到单模块模式，完全无视go.work。
- 现象：子模块里
go run .失败，提示找不到其他本地模块 - 根本原因：Go 不会跨目录自动向上查找
go.work，必须显式处于工作区根（即go.work所在目录） - 验证方式：执行
go work edit，只有在根目录下才输出模块列表；进子目录后该命令直接报错 - 临时补救：用
go build -o ./bin/ ./service_a这种显式路径写法，但不推荐——易漏、难维护
go.work use路径必须相对且静态，不能带../或变量
go.work里的use路径是硬编码的相对路径，解析基准永远是go.work文件所在目录。写错路径不仅加载失败，还可能静默忽略——Go 不报错，只是不加载。
- 正确写法：
use ./lib_b（假设lib_b/与go.work同级） - 错误写法：
use ../lib_b、use $HOME/myproj/lib_b、use */lib_b - 路径变更后必须同步改
go.work：比如把service_a重命名为api，就得手动改use ./service_a为use ./api - IDE（如 VS Code）依赖此路径做代码跳转，路径错会导致 import 提示灰色、无法 Ctrl+Click 跳转
子模块go.mod里残留的replace会劫持工作区逻辑
replace优先级高于go.work use。只要某个子模块的go.mod里还留着replace example.com/lib => ../lib，Go 就永远走这条路径，哪怕go.work已声明use ./lib也无效。
- 检查命令：
grep replace service_a/go.mod - 清理动作：删掉所有
replace行，再运行go mod tidy（此时会报错，因为远程模块不存在——这正是预期，说明工作区接管成功） - 例外情况：仅当你要临时覆盖某个第三方模块（如
replace golang.org/x/net => ./vendor/x/net）才保留replace，且必须确保它不指向其他本地模块 - Git 提交前务必确认：
git diff -- go.work go.mod，避免误提交replace干扰协作
CI/CD 里不能直接用go work，得降级处理
标准 CI 环境（GitHub Actions、GitLab CI）默认不启用工作区模式，go build会彻底忽略go.work。这不是 bug，是设计使然——工作区是纯本地开发机制。
- CI 中正确做法：删掉
go.work，用go mod edit -replace还原成传统依赖管理，或发布正式版本后require - 自动化脚本建议：
if [ -f go.work ]; then go mod edit -dropreplace; fi，清理后再go mod tidy - 测试阶段可保留工作区：CI 里跑
go test ./...时，只要在根目录执行，仍能利用工作区加载最新代码——但构建产物必须用非工作区方式生成 - 关键提醒：不要在
.gitignore里忽略go.work，它需纳入版本控制；但也不要在 CI 脚本里go work init——CI 没有“本地开发”语义
真正卡住人的从来不是语法，而是路径层级和执行上下文这两个隐形开关。每次遇到问题，先pwd看目录，再go work edit看是否识别，最后grep replace扫一遍——三步做完，90% 的协作问题就定位完了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
