本页介绍了 Bazel 的两个可见性系统：目标可见性和加载可见性。
这两种可见性有助于其他开发者区分库的公共 API 和实现详情，并有助于在工作区不断扩大的情况下强制执行结构。您还可以在弃用公共 API 时使用可见性，以允许当前用户使用该 API，同时拒绝新用户使用。
目标可见性
目标可见性用于控制哪些人可以依赖您的目标，也就是说，哪些人可以在属性（例如 deps）中使用目标的标签。
如果目标 A 和目标 B 位于同一软件包中，或者 A 向 B 的软件包授予了可见性，则 A 对 B 可见。因此，软件包是决定是否允许访问的粒度单位。如果 B 依赖于 A，但 A 对 B 不可见，那么在分析期间，任何构建 B 的尝试都会失败。
请注意，授予软件包的可见性本身并不会授予其子软件包的可见性。如需详细了解软件包和子软件包，请参阅概念和术语。
对于原型设计，您可以通过设置标志 --check_visibility=false 来停用目标可见性强制执行。对于提交的代码，不应在生产环境中使用此方法。
控制可见性的主要方法是在规则目标上使用 visibility 属性。本部分介绍了此属性的格式，以及如何确定目标的可见性。
公开范围规范
所有规则目标都具有 visibility 属性，该属性接受标签列表。每个标签都具有以下形式之一。除了最后一种形式之外，这些都只是语法占位符，不对应于任何实际目标。
"//visibility:public"：授予对所有软件包的访问权限。（不得与任何其他规范结合使用。）"//visibility:private"：不授予任何其他访问权限；只有此软件包中的目标可以使用此目标。（可能无法与其他任何规范叠加使用。）"//foo/bar:__pkg__"：授予对//foo/bar（但不是其子软件包）的访问权限。"//foo/bar:__subpackages__"：授予对//foo/bar及其所有直接和间接子软件包的访问权限。"//some_pkg:my_package_group"：授予对给定package_group中所有软件包的访问权限。- 软件包组使用不同的语法来指定软件包。在软件包组中，形式
"//foo/bar:__pkg__"和"//foo/bar:__subpackages__"分别替换为"//foo/bar"和"//foo/bar/..."。同样，"//visibility:public"和"//visibility:private"只是"public"和"private"。
- 软件包组使用不同的语法来指定软件包。在软件包组中，形式
例如，如果 //some/package:mytarget 的 visibility 设置为 [":__subpackages__", "//tests:__pkg__"]，则 //some/package/... 源树中的任何目标以及在 //tests/BUILD 中定义的目标都可以使用它，但在 //tests/integration/BUILD 中定义的目标不能使用它。
最佳实践：为了让同一组软件包看到多个目标，请使用 package_group，而不是在每个目标的 visibility 属性中重复该列表。这样可以提高可读性，并防止列表不同步。
规则目标公开范围
规则目标的可见性为：
其
visibility属性的值（如果已设置）；否则目标
BUILD文件中package语句的default_visibility实参的值（如果存在此类声明）；否则//visibility:private。
最佳实践：避免将 default_visibility 设置为公开。这对于原型设计或小型代码库可能很方便，但随着代码库的增长，意外创建公开目标的风险也会增加。最好明确指出哪些目标是软件包公共接口的一部分。
示例
文件 //frobber/bin/BUILD：
# This target is visible to everyone
cc_binary(
name = "executable",
visibility = ["//visibility:public"],
deps = [":library"],
)
# This target is visible only to targets declared in the same package
cc_library(
name = "library",
# No visibility -- defaults to private since no
# package(default_visibility = ...) was used.
)
# This target is visible to targets in package //object and //noun
cc_library(
name = "subject",
visibility = [
"//noun:__pkg__",
"//object:__pkg__",
],
)
# See package group "//frobber:friends" (below) for who can
# access this target.
cc_library(
name = "thingy",
visibility = ["//frobber:friends"],
)
文件 //frobber/BUILD：
# This is the package group declaration to which target
# //frobber/bin:thingy refers.
#
# Our friends are packages //frobber, //fribber and any
# subpackage of //fribber.
package_group(
name = "friends",
packages = [
"//fribber/...",
"//frobber",
],
)
生成的文件目标公开范围
生成的文件的目标与生成它的规则目标具有相同的可见性。
源文件目标公开范围
您可以通过调用 exports_files 明确设置源文件目标的可见性。如果未向 exports_files 传递 visibility 实参，则会将公开范围设为公开。
exports_files 不得用于替换生成文件的公开范围。
对于未在 exports_files 的调用中显示的目标源文件，其可见性取决于标志 --incompatible_no_implicit_file_export 的值：
如果设置了该标志，则公开范围为“私享”。
否则，应用旧版行为：公开范围与
BUILD文件的default_visibility相同；如果未指定默认公开范围，则为私享。
避免依赖旧版行为。只要源文件目标需要非私密的可视性，就始终写入 exports_files 声明。
最佳实践：尽可能优先公开规则目标，而不是源文件。例如，不要对 .java 文件调用 exports_files，而是将该文件封装在非私有的 java_library 目标中。一般来说，规则目标应仅直接引用位于同一软件包中的源文件。
示例
文件 //frobber/data/BUILD：
exports_files(["readme.txt"])
文件 //frobber/bin/BUILD：
cc_binary(
name = "my-program",
data = ["//frobber/data:readme.txt"],
)
配置设置可见性
过去，对于在 select() 的键中引用的 config_setting 目标，Bazel 不会强制执行可见性。有两个标志可用于移除此旧版行为：
--incompatible_enforce_config_setting_visibility可针对这些目标启用可见性检查。为了帮助进行迁移，它还会导致任何未指定visibility的config_setting被视为公开（无论软件包级default_visibility如何）。--incompatible_config_setting_private_default_visibility会导致未指定visibility的config_setting遵循软件包的default_visibility并回退到私有可见性，就像任何其他规则目标一样。如果未设置--incompatible_enforce_config_setting_visibility，则此方法不执行任何操作。
避免依赖旧版行为。如果软件包尚未指定合适的 default_visibility，则任何打算在当前软件包之外使用的 config_setting 都应具有明确的 visibility。
软件包组目标可见性
package_group 目标缺少 visibility 属性。它们始终公开显示。
隐式依赖关系的可见性
有些规则具有隐式依赖项，即未在 BUILD 文件中明确列出，但对于该规则的每个实例而言都是固有的依赖项。例如，cc_library 规则可能会从其每个规则目标创建到表示 C++ 编译器的可执行目标的隐式依赖项。
此类隐式依赖项的公开范围是根据包含定义规则（或方面）的 .bzl 文件的软件包来检查的。在我们的示例中，只要 C++ 编译器与 cc_library 规则的定义位于同一软件包中，就可以是私有的。作为后备方案，如果从定义中看不到隐式依赖项，则会针对 cc_library 目标进行检查。
您可以通过停用 --incompatible_visibility_private_attributes_at_definition 来更改此行为。如果停用，隐式依赖项将与其他依赖项一样处理。这意味着，所依赖的目标（例如我们的 C++ 编译器）必须对规则的每个实例可见。实际上，这通常意味着目标必须具有公开可见性。
如果您想将规则的使用限制为仅限某些软件包，请改用加载可见性。
加载可见性
加载可见性用于控制是否可以从当前软件包之外的其他 BUILD 或 .bzl 文件加载 .bzl 文件。
与目标可见性保护由目标封装的源代码的方式类似，加载可见性保护由 .bzl 文件封装的 build 逻辑。例如，BUILD 文件作者可能希望将一些重复的目标定义分解为 .bzl 文件中的宏。如果没有负载可见性保护，他们可能会发现自己的宏被同一工作区中的其他协作者重复使用，从而导致修改宏会破坏其他团队的 build。
请注意，.bzl 文件可能具有也可能不具有对应的源文件目标。
如果确实如此，则无法保证负载可见性和目标可见性一致。也就是说，同一个 BUILD 文件可能能够加载 .bzl 文件，但无法在 filegroup 的 srcs 中列出该文件，反之亦然。这有时会给希望将 .bzl 文件作为源代码使用的规则（例如用于生成文档或进行测试）带来问题。
对于原型设计，您可以通过设置 --check_bzl_visibility=false 来停用加载可见性强制执行。与 --check_visibility=false 一样，不应针对已提交的代码执行此操作。
自 Bazel 6.0 起，即可使用加载可见性。
声明加载可见性
如需设置 .bzl 文件的加载公开范围，请从该文件内调用 visibility() 函数。visibility() 的实参是一个软件包规范列表，与 package_group 的 packages 属性一样。不过，visibility() 不接受负的软件包规范。
对 visibility() 的调用必须仅在每个文件中发生一次，位于顶层（不在函数内），最好紧跟在 load() 语句之后。
与目标公开范围不同，默认加载公开范围始终为公开。不调用 visibility() 的文件始终可以从工作区中的任何位置加载。最好在任何并非专门用于在软件包外部使用的新 .bzl 文件的顶部添加 visibility("private")。
示例
# //mylib/internal_defs.bzl
# Available to subpackages and to mylib's tests.
visibility(["//mylib/...", "//tests/mylib/..."])
def helper(...):
...
# //mylib/rules.bzl
load(":internal_defs.bzl", "helper")
# Set visibility explicitly, even though public is the default.
# Note the [] can be omitted when there's only one entry.
visibility("public")
myrule = rule(
...
)
# //someclient/BUILD
load("//mylib:rules.bzl", "myrule") # ok
load("//mylib:internal_defs.bzl", "helper") # error
...
加载可见性实践
本部分介绍了有关管理负载可见性声明的提示。
公开范围的因式分解
如果多个 .bzl 文件应具有相同的可见性，则将它们的软件包规范纳入一个通用列表会很有帮助。例如：
# //mylib/internal_defs.bzl
visibility("private")
clients = [
"//foo",
"//bar/baz/...",
...
]
# //mylib/feature_A.bzl
load(":internal_defs.bzl", "clients")
visibility(clients)
...
# //mylib/feature_B.bzl
load(":internal_defs.bzl", "clients")
visibility(clients)
...
这有助于防止各种 .bzl 文件的可见性出现意外偏差。当 clients 列表较大时，此方法也更易于阅读。
组合公开范围
有时，.bzl 文件可能需要对由多个较小的许可名单组成的许可名单可见。这类似于 package_group 如何通过其 includes 属性来纳入其他 package_group。
假设您要弃用一个广泛使用的宏。您希望它仅对现有用户和您自己团队拥有的软件包可见。您可以这样写：
# //mylib/macros.bzl
load(":internal_defs.bzl", "our_packages")
load("//some_big_client:defs.bzl", "their_remaining_uses")
# List concatenation. Duplicates are fine.
visibility(our_packages + their_remaining_uses)
使用软件包组进行去重
与目标可见性不同，您无法以 package_group 的形式定义加载可见性。如果您想针对目标可见性和加载可见性重复使用同一许可名单，最好将软件包规范列表移至 .bzl 文件中，以便两种声明都可以引用该列表。在上面的分解可见性示例的基础上，您可以编写以下代码：
# //mylib/BUILD
load(":internal_defs", "clients")
package_group(
name = "my_pkg_grp",
packages = clients,
)
仅当列表不包含任何负软件包规范时，此方法才有效。
保护单个符号
名称以下划线开头的任何 Starlark 符号都无法从其他文件加载。这样一来，您就可以轻松创建私密符号，但无法与一组有限的可信文件共享这些符号。另一方面，加载可见性可让您控制其他软件包可以看到哪些 .bzl file，但不允许您阻止加载任何非下划线符号。
幸运的是，您可以结合使用这两项功能，从而实现精细控制。
# //mylib/internal_defs.bzl
# Can't be public, because internal_helper shouldn't be exposed to the world.
visibility("private")
# Can't be underscore-prefixed, because this is
# needed by other .bzl files in mylib.
def internal_helper(...):
...
def public_util(...):
...
# //mylib/defs.bzl
load(":internal_defs", "internal_helper", _public_util="public_util")
visibility("public")
# internal_helper, as a loaded symbol, is available for use in this file but
# can't be imported by clients who load this file.
...
# Re-export public_util from this file by assigning it to a global variable.
# We needed to import it under a different name ("_public_util") in order for
# this assignment to be legal.
public_util = _public_util
bzl-visibility Buildifier lint
如果用户从名为 internal 或 private 的目录加载文件，但用户的文件本身不在该目录的父目录下，则 Buildifier lint 会发出警告。此 lint 早于加载可见性功能，在 .bzl 文件声明可见性的工作区中是不必要的。