Bazel 基于源代码构建软件，这些源代码以目录树的形式组织，称为
工作区。工作区中的源文件以嵌套的软件包层次结构进行整理，其中每个软件包都是一个目录，其中包含一组相关的源文件和一个 BUILD 文件。BUILD 文件用于指定
可以在源代码的基础上构建输出
工作区
工作区是文件系统中的一个目录树，其中包含要构建的软件的源文件。每个工作区都有一个名为
WORKSPACE，可能为空，或可能包含对 external
构建输出所需的依赖项。
包含 WORKSPACE 文件的目录被视为
工作区。因此，Bazel 会忽略根目录位于包含 WORKSPACE 文件的子目录的工作区中的任何目录树，因为它们会形成另一个工作区。
Bazel 还支持将 WORKSPACE.bazel 文件用作 WORKSPACE 文件的别名。如果
两个文件都存在，系统会使用 WORKSPACE.bazel。
代码库
代码整理到各个repositories中。包含 WORKSPACE 文件的目录是主代码库的根目录，也称为 @。其他（外部）代码库是在 WORKSPACE 文件中使用工作区规则定义的，或从 Bzlmod 系统中的模块和扩展程序生成的。如需了解详情，请参阅外部依赖项概览。
与 Bazel 捆绑的工作区规则记录在构建百科全书的工作区规则部分以及嵌入式 Starlark 代码库规则文档中。
由于外部代码库本身就是代码库，因此它们通常也包含 WORKSPACE 文件。不过，Bazel 会忽略这些额外的 WORKSPACE 文件。特别是，以传递方式依赖的仓库
自动添加。
软件包
代码库中代码组织的主要单元是软件包。答 package 是相关文件的集合，以及有关如何使用它们的 用于生成输出工件。
软件包定义为包含名为 BUILD 或 BUILD.bazel 的 BUILD 文件的目录。答
package 包含其目录中的所有文件及其下的所有子目录，
本身包含 BUILD 文件的那些文件除外。根据此定义，任何文件或目录都不能属于两个不同的软件包。
例如，在以下目录树中，有两个软件包 my/app 和子软件包 my/app/tests。请注意，my/app/data 不是软件包，
属于软件包 my/app 的目录。
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
目标
软件包是目标的容器，这些目标在软件包的 BUILD 文件中定义。大多数目标属于两种主要类型之一，即文件和规则。
文件进一步分为两种类型。源文件通常由 并签到代码库。生成的文件（有时称为派生文件或输出文件）不会被提交，而是从源文件生成。
第二种目标是使用规则声明的。每个规则实例都指定一组输入文件与一组输出文件之间的关系。通过 规则的输入可以是源文件，但也可以是其他 规则。
规则的输入是源文件还是生成的文件， 无实质性的情况；重要的只是该文件的内容事实 可以轻松将复杂的源文件替换为 例如，必须手动维护 结构化文件变得令人厌烦，有人编写程序来派生它。 该文件的使用者无需进行任何更改。相反， 文件可以轻而易举地替换为只进行本地更改的源文件。
规则的输入可能还包括“其他规则”。此类的确切含义 往往非常复杂，且取决于语言或规则， 直观地说，这很简单：C++ 库规则 A 可能具有另一个 C++ 库 规则 B。这种依赖项的影响是，在编译期间，A 可以使用 B 的头文件；在链接期间，A 可以使用 B 的符号；在执行期间，A 可以使用 B 的运行时数据。
所有规则的一个不变性是，由规则生成的文件始终与规则本身属于同一软件包；无法将文件生成到其他软件包中。规则的输入来自另一个规则，这种情况很常见。 还是“软件包”
软件包组是一组软件包，旨在限制对某些规则的访问权限。软件包组由 package_group 函数定义。他们
具有三个属性：其所含软件包的列表、名称以及其他
它们包含的软件包组。引用这些变量的唯一方式是
规则的 visibility 属性，或来自以下规则的 default_visibility 属性：
package 函数；而不会生成或使用文件有关
信息，请参阅 package_group
文档。