根本原因是未在go.work所在目录执行命令，Go工作区仅在该目录及子目录生效；须确保当前工作目录为go.work根目录、use路径为相对路径、删除子模块go.mod中旧require，并优先用go work use而非replace。
go work 里模块 still not in main module 怎么办
根本原因不是路径写错，而是你没在 go.work 所在目录执行命令。Go 工作区只在 go.work 文件所在目录及其子目录生效，且仅当命令由该上下文触发时才启用多模块解析。
常见错误现象：go build 报 module xxx is not in main module，但 go.work 明明写了 use ./service_a。
- 确认当前 shell 工作目录是
go.work所在根目录（不是./service_a内部） - 检查
go.work中的use路径是否为相对路径，且不带../或绝对路径 - 运行
go work use -r列出当前工作区已加载的模块，确认目标模块在其中 - 如果子模块
go.mod里还保留着旧的require example.com/lib v0.1.0，删掉它——工作区模式下本地路径优先，require 版本反而会干扰解析
replace 和 go work use 冲突了怎么选
replace 和 go work use 都能重定向依赖，但优先级不同：后者更高，且作用范围是整个工作区；前者只作用于单个模块的 go.mod，且会覆盖工作区行为。
容易踩的坑：你在 service_a/go.mod 里写了 replace github.com/my/lib => ../lib，又在 go.work 里 use ./lib，结果 service_a 仍然加载的是 ../lib 而非工作区里的 ./lib。
立即学习“go语言免费学习笔记（深入）”；
- 开发阶段一律优先用
go work use，删掉所有本地路径replace -
replace只应在两种场景保留：指向 fork 的远程仓库（如github.com/yourname/pkg v1.4.2），或临时调试未提交的 commit（如v0.0.0-20231015120000-abcdef123456） - CI 构建前必须确保
go.work中无replace指向本地路径，否则构建失败
为什么 go list -m all 显示多个版本却没报错
Go 允许多版本共存是设计使然，不是 bug。只要不同模块 require 的版本满足语义化兼容（比如 v1.2.0 和 v1.5.0 属于同一主版本），它们就能并存，各自编译、互不影响。
真正危险的是跨主版本冲突，比如一个模块 require github.com/some/lib/v2，另一个 require github.com/some/lib（即 v1），这时 Go 会同时加载两个包——因为导入路径不同，但行为可能意外耦合。
- 用
go mod graph | grep some/lib查看哪些模块引入了哪个路径 - 若发现
some/lib和some/lib/v2同时存在，说明有模块未升级到 v2，需协调统一导入路径 -
go list -m all中重复出现的模块名（不含 /vN）通常只是间接依赖残留，go mod tidy不会自动删，除非它真没被任何 import 引用
go work 下如何验证依赖是否真被本地模块接管
不能只看 go.work 文件是否存在，得验证实际加载路径是否变成本地源码。
最直接的方法是改一行本地模块的代码（比如加个日志），然后在引用它的其他模块中运行 go run，看是否生效。不生效？说明没接管成功。
- 执行
go list -m -f '{{.Dir}}' github.com/your-org/lib，输出应为本地路径（如/path/to/my_monorepo/lib），而不是$GOPATH/pkg/mod - 检查
go mod graph输出中，该模块的依赖边是否指向=>本地路径，而非远程版本号 - 如果仍拉取远程版本，先运行
go mod edit -dropreplace github.com/your-org/lib清掉残留replace，再go mod tidy
go.work 加入，模块 B 却没加，但 B 的代码里 import 了 A 的包，此时 Go 不会自动帮你 resolve，也不会报错，只会默默 fallback 到远程版本。这种静默 fallback 最难排查。 
