我有一个包含多种主要方法的项目。当运行go build program1/main1.go具有不同的依赖项集时program2/main2.go，我的第一个go build似乎更改了我的go.mod文件并删除了它认为不需要的依赖项。然而main2将需要这些依赖项。
我尝试过使用go build ...，但这也创建了一组不同的依赖项。具体来说，似乎所有//indirect依赖项都被删除并导致 program2 失败。
有没有办法运行go build或go run不更新go.mod文件？使用go build -mod=readonly program1/main1.go它告诉我它失败了，因为需要更新依赖项..
使用子模块是一种嵌套多个 Go 模块项目的方法，您可以编辑它。
但是 Go 1.18 可能包含Go 工作区的概念，这意味着您不再需要子模块：一个Go 项目可以包含多个您可以编辑的模块。
请参阅golang/go问题 45713：“提案：：cmd/go添加工作区模式”及其设计文档。
背景
用户经常希望跨多个模块进行更改：例如，在一个模块的包中引入一个新接口，同时在另一个模块中使用该接口。
通常，该
go命令识别用户可以编辑的单个“main”模块。
其他模块是只读的，从模块缓存中加载。该
go mod replace指令是一个例外：它允许用户用磁盘上的工作版本替换模块的解析版本。
但是使用replace指令通常会很尴尬：每个模块开发人员可能在磁盘上的不同位置都有工作版本，因此将指令放在需要与模块一起分发的文件中并不适合所有用例。提议
该提案在
go命令中描述了用于编辑多个模块的新工作区模式。工作目录或包含目录中存在
go.work文件将使go命令进入工作区模式。
该go.work文件指定了一组组成工作空间的本地模块。在工作区模式下调用时，该go命令将始终选择这些模块和一组一致的依赖项。主要模块：用户正在使用的模块。
在此提议之前，这是包含go调用命令的目录的单个模块。此模块用作运行 MVS 时的起点。
该提案建议允许多个主要模块。
参见例如CL 334934（CL = 更改列表）
[
dev.cmdgo]cmd/go: 添加工作区模式此更改添加了工作区模式的实施大纲。
该
go命令现在将定位go.work文件，并读取它们以确定哪些模块在工作区中。
然后，它会在构建构建列表时将这些模块放在工作区的根目录中。
它支持在工作区中构建、运行、测试和列出。
您可以启动一个多模块项目go mod initwork
同样，这不是在 Go 1.18（2022 年第一季度）之前，并且可能会在 Go 1.19（2022 年第三季度）中选择加入。