Bazel 模块是可以有多个版本的 Bazel 项目，每个版本都会发布有关它所依赖的其他模块的元数据。这类似于其他依赖项管理系统（如 Maven 工件、npm 软件包、Go 模块或 Cargo crate）中熟悉的概念。
模块的代码库根目录下必须有一个 MODULE.bazel 文件（WORKSPACE 文件旁边）。此文件是模块的清单，用于声明模块名称、版本、直接依赖项列表以及其他信息。基本示例：
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
请参阅 MODULE.bazel 文件中提供的指令的完整列表。
为了执行模块解析，Bazel 会先读取根模块的 MODULE.bazel 文件，然后从 Bazel 注册表中反复请求任何依赖项的 MODULE.bazel 文件，直到发现整个依赖关系图为止。
默认情况下，Bazel 会选择要使用的每个模块的一个版本。Bazel 通过代码库表示每个模块，并再次咨询注册表，以了解如何定义每个代码库。
版本格式
Bazel 具有多元化的生态系统，并且项目采用不同的版本控制方案。到目前为止，最受欢迎的是 SemVer，但也有一些采用不同架构的知名项目，例如 Abseil，其版本基于日期，例如 20210324.2。
因此，Bzlmod 采用了更宽松的 SemVer 规范版本。与它们之间的区别包括：
- SemVer 规定版本的“发布”部分必须由 3 个细分组成：
MAJOR.MINOR.PATCH。在 Bazel 中，此要求放宽了，以允许任意数量的细分。 - 在 SemVer 中，“发布”部分中的每个片段只能是数字。 在 Bazel 中，这也放宽了为允许使用字母，并且比较语义与“预发布”部分中的“标识符”相匹配。
- 此外，系统不会强制执行主要版本、次要版本和补丁版本提高的语义。不过，如需详细了解我们如何表示向后兼容性，请参阅兼容性级别。
任何有效的 SemVer 版本都是有效的 Bazel 模块版本。此外，当与 Bazel 模块版本进行比较时，当且仅当相同的 SemVer 版本a和b进行比较时，a < b才会比较二者。
版本选择
请考虑菱形依赖项问题，这是版本化依赖项管理空间中的关键所在。假设您有以下依赖关系图：
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
应使用哪个版本的 D？为了解决此问题，Bzlmod 使用 Go 模块系统中引入的最低版本选择 (MVS) 算法。MVS 假定模块的所有新版本都向后兼容，因此会选择任何依赖项指定的最高版本（在我们的示例中为 D 1.1）。之所以称为“最低”版本，是因为 D 1.1 是可以满足要求的最早版本。即使存在 D 1.2 或更高版本，我们也不会选择它们。使用 MVS 可以创建高保真度且可重现的版本选择过程。
引用的版本
如果需要避免某些版本（例如为了防范安全漏洞），注册表可以将某些版本声明为“拉取”。选择拉取的模块版本时，Bazel 会抛出错误。如需修复此错误，请升级到较新的非拉取版本，或使用 --allow_yanked_versions 标志明确允许拉取的版本。
兼容性级别
在 Go 中，MVS 关于向后兼容的假设是可行的，因为它将模块的向后不兼容版本视为单独的模块。对于 SemVer，这意味着 A 1.x 和 A 2.x 被视为不同的模块，并且可以共存于已解析的依赖关系图中。这又是通过对 Go 软件包路径中的主要版本进行编码来实现的，因此不存在任何编译时或链接时冲突。
但是，Bazel 无法提供此类保证，因此它需要“主要版本”编号才能检测向后不兼容的版本。此编号称为“兼容性级别”，由每个模块版本在其 module() 指令中指定。了解这些信息后，Bazel 可能会在检测到已解析的依赖关系图中存在具有不同兼容性级别的同一模块的版本时抛出错误。
覆盖对象
在 MODULE.bazel 文件中指定替换项，以更改 Bazel 模块解析的行为。只有根模块的替换项才会生效 - 如果模块用作依赖项，其替换项会被忽略。
每个替换项都为特定模块名称指定，这会影响依赖项图中的所有版本。虽然只有根模块的替换项才会生效，但它们可能适用于根模块不直接依赖的传递依赖项。
单个版本替换
single_version_override 有多种用途：
- 借助
version属性，您可以将依赖项固定到特定版本，无论在依赖关系图中请求哪个版本的依赖项。 - 您可以使用
registry属性强制此依赖项来自特定注册表，而不是遵循常规的注册表选择流程。 - 借助
patch*属性，您可以指定一组要应用于已下载的模块的补丁。
这些属性都是可选的，并且可以相互混合和匹配。
多个版本替换
您可以指定 multiple_version_override，以允许同一模块的多个版本在已解析的依赖关系图中共存。
您可以为模块指定明确的允许版本列表，在解析之前，必须全部出现在依赖关系图中 - 必须存在某个传递依赖项，具体取决于每个允许的版本。问题解决后，只会保留模块允许的版本，而 Bazel 会将模块的其他版本升级到在相同兼容性级别下最接近的允许版本。如果在相同兼容性级别下不存在允许更高的版本，Bazel 会抛出错误。
例如，如果依赖项图中存在版本 1.1、1.3、1.5、1.7 和 2.0 的版本早于解决方法，并且主要版本是兼容性级别：
- 允许
1.3、1.7和2.0的多版本替换会导致1.1升级到1.3，1.5升级到1.7，而其他版本保持不变。 - 允许
1.5和2.0的多版本替换会导致错误，因为1.7没有具有相同兼容性级别的更高版本。 - 如果允许
1.9和2.0的多版本替换会导致错误，因为在解析之前，依赖关系图中不存在1.9。
此外，用户还可以使用 registry 属性替换注册表，操作方式与单个版本替换类似。
非注册表覆盖
非注册表替换会完全从版本解析中移除模块。Bazel 不会从注册表请求这些 MODULE.bazel 文件，而是从代码库本身请求。
Bazel 支持以下非注册表替换：
代码库名称和严格依赖项
支持模块的代码库的规范名称是 module_name~version（例如 bazel_skylib~1.0.3）。对于具有非注册表替换的模块，请将 version 部分替换为字符串 override。请注意，规范名称格式不是您应该依赖的 API，并且随时可能更改。
支持模块至其直接依赖项的代码库的表观名称默认为其模块名称，除非 bazel_dep 指令的 repo_name 属性另有说明。请注意，这意味着模块只能找到其直接依赖项。这有助于防止因传递依赖项更改而导致意外中断。
模块扩展还可以在模块的可见范围内引入其他代码库。