亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《一个项目中的各个不同模块》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

我一直在使用 go 模块，我想知道以下目录结构的最佳实践是什么：

project
├── go.mod
├── main.go
└── players
    ├── go.mod
    ├── players.go
    └── players_test.go

一开始我在将 players 包导入我的根项目时遇到问题，但我注意到我可以在根 go.mod 文件中执行此操作

module github.com//

require (
    github.com//players v0.0.0
)

replace github.com//players => ./players

这允许我在我的 main.go 文件中执行 import "github.com//players" 。

现在这种方法可以工作，并且是从这里获取的，但我不确定这是否是正确的方法，或者这种方法是否只是用于在版本控制之外临时更新本地包。

另一个选项，似乎有点矫枉过正，是让每个模块都有自己的存储库？

tl;博士; - 在同一存储库中拥有多个模块并将它们导入其他模块/根 main.go 文件的最佳实践方法是什么？

解决方案

一般来说，模块应该是包的集合。

但是您仍然可以创建单个包的模块。正如 Volker 所说，如果您希望这些包具有不同的生命周期，这可能才有意义。当您想从另一个项目导入这些模块并且不希望整个包集合的开销时，它也可能是有意义的。

一般情况：

模块是相关 go 包的集合，它们作为一个单元一起进行版本控制。

模块记录精确的依赖关系需求并创建可重现的构建。

大多数情况下，版本控制存储库仅包含存储库根中定义的一个模块。 （单个存储库支持多个模块，但通常这会导致比每个存储库单个模块更多的持续工作）。

总结存储库、模块和包之间的关系：

1. 存储库包含一个或多个 go 模块。 2. 每个模块包含一个或多个go包。 3. 每个包由一个或多个位于单个目录中的go源文件组成。

报价来源：https://github.com/golang/go/wiki/Modules#modules

回答问题：

您可以按照您的方法中所示的方式来实现

我知道这是一个老问题，但是在管理一个存储库中的多个模块时，还有一些细节值得一提，使用或没有 go.work。

tl;dr

每种方法都有优点和缺点，但如果您正在处理包含许多模块的大型代码库，我建议坚持使用基于提交或标签的版本处理，并使用 go workspace 进行日常开发。

go 模块详细信息

replace 无版本控制指令

当您使用指向本地目录的 replace 指令时，您会发现依赖模块的版本为 v0.0.0-00010101000000-000000000000。本质上你得不到版本信息。

使用 github.com/name/project 模块路径定义主 go.mod 时，github.com/name/project 模块无法进行可重现的构建，因为 replace 指令的依赖项目标可能已更新其内容。如果 github.com/name/project/players 的依赖目标被许多模块使用，这可能会特别成问题。这种公共包中的任何更改都可能导致所有依赖项同时发生行为改变。

如果这不是您关心的问题，replace 指令应该可以正常工作。在这样的设置中，go.work 可能是您并不真正需要的层。

带有版本控制

如果您想确保版本设置适用于多个模块的可重复且确定性的构建，您可以采取几种不同的方法。

一个 go.mod，一个存储库

这可能是最简单的方法。对于每个模块，都有清晰的提交历史记录和版本控制。只要您通过远程存储库引用该模块，这可能是最容易开始的设置，并且依赖项设置非常清晰。

但是，请注意，这种方法意味着您需要管理多个存储库，并且让 go.work 提供帮助将需要适当的本地目录映射，这对于刚接触代码库的人来说可能很困难。 p>

基于提交的版本控制

仍然可以确定性地定义版本信息的依赖关系，以便您可以在单个存储库中构建代码。基于提交的方法需要最少的步骤，并且仍然可以很好地工作。不过，有一些问题需要注意。

• 要使 github.com/name/project 依赖于 github.com/name/project/players，您需要确保所需的代码位于远程存储库中。这是因为 github.com/name/project 将从远程存储库中提取代码并提交信息，即使存储库的本地副本上有相同的代码。这可确保 github.com/name/project/players 的版本取自提交参考，例如 v0.1.1-0.20220418015705-5f504416395d （参考：details of "pseudo-version"）
• 模块名称必须与目录结构匹配。例如，如果您有单个存储库 github.com/name/project，模块位于 /src/mymodule/ 下，则模块名称必须为 github.com/name/project/src/mymodule。这是因为当模块路径解析发生时，go 会找到存储库的根（在上面的示例中，这将是 github.com/name/project.git），然后尝试根据模块名称遵循目录路径。
• 如果您在私有存储库中工作，则需要确保 go.sum 检查不会阻止您。您只需使用 goprivate=github.com/name/project 来指定您不希望跳过校验和验证的路径。

基于标签的版本控制

您可以使用 git 标签，而不是使用提交 sha。

但是由于一个存储库中可能有许多模块，go module 需要找到哪个标签映射到哪个标签。例如，具有以下目录结构：

# all assumed to be using `github.com/name/project` prefix before package name
mypackage/          # v1.0.0
anotherpackage/     # v0.5.1
nested/dependency/  # v0.8.3

您需要在 github.com/name/project 中创建标签，其命名与目录结构完全匹配，例如：

mypackage/v1.0.0
anotherpackage/v0.5.1
nested/dependency/v0.8.3

这样，go module 就能正确引用每个标签，并且您的依赖关系可以保持确定性。

go.work 行为

如果 go 工作的父目录中有 go.work，请使用 github.com/name/project/players 等，该目录优先并使用本地文件。即使您在 go.mod 中指定了版本，情况也是如此。

对于跨多个项目的本地开发，go workspace 是一次处理多个事情的好方法，而无需首先推送依赖项的代码更改。但同时，实际发布仍然需要分解提交，以便稍后在其他代码更改中引用第一次提交。

go.work 据说是一个很少需要提交到存储库的文件。不过，您必须了解在父路径中包含 go.work 会产生什么影响。

--

参考文献：

• https://go.dev/doc/modules/managing-source：围绕存储库设置的讨论
• https://go.dev/ref/mod：go 模块参考

旁注：

我在日本举办的 go 会议上对此进行了演讲 - 如果您想通过示例了解更多信息，您可以找到一些演示代码、幻灯片等。here。

本篇关于《一个项目中的各个不同模块》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！