Go官方不支持单项目多go.mod，多个go.mod表示多个独立模块；常见原因有子模块、vendor残留或路径错误；仅最近祖先go.mod生效，需通过go list -m等命令确认模块上下文。
Go 语言官方不支持一个项目中存在多个 go.mod 文件——它们不是“可共存的配置文件”，而是模块边界定义文件。如果你看到多个 go.mod，说明你面对的是多个独立模块（可能是子模块、vendor 内嵌、或误操作残留），而非“同一个项目里管理多个 go.mod”。
为什么会出现多个 go.mod 文件
常见真实场景有三种：
- 项目包含可独立发布的子模块（如
github.com/user/repo/cli和github.com/user/repo/lib），每个子目录下初始化了go mod init，形成多模块结构 -
vendor/目录被手动保留且内部有go.mod（Go 1.14+ 已弃用 vendor 模式，该文件通常无实际作用） - 执行
go mod init时路径错误（比如在子目录而非仓库根目录运行），导致生成了嵌套的、非预期的go.mod
如何判断哪些 go.mod 是有效的模块入口
Go 工具链只认当前工作目录向上查找遇到的第一个 go.mod（即最近的祖先模块）。你可以用以下方式验证：
- 运行
go list -m：它输出当前生效的主模块（即你所在目录所属的模块） - 运行
go list -m all：列出所有被主模块直接或间接依赖的模块，包括本地 replace 的路径模块 - 检查
replace语句：如果某子目录被replace ./sub => ./sub显式引用，那它虽有go.mod，但只是本地开发模块，不发布
注意：go build 或 go test 不会自动切换到子目录的 go.mod；除非你 cd ./sub && go build，否则子模块的 go.mod 不参与构建。
