对于每个this doc，分析和执行阶段分别负责构建依赖关系树（以及其他事项），并在需要时进行工作。如果是这样，我很好奇为什么目标总数会随着构建的进行而不断增加（即，当我开始进行大型构建时，bazel可能会报告说它已经构建了100个目标中的5个，但后来会说它构建了20个目标300个目标，依此类推，分母会增加一段时间，直到稳定为止。
我听说加载和分析阶段可以混合在一起。我可能不完整或不正确的理解是，当bazel解析BUILD文件时，将调用分析以确定命令行上所请求目标所需的依赖项，然后我猜想这是以某种方式传达回加载器以拉入任何其他文件这些依赖项引用的BUILD文件，如果依赖项（以及BUILD文件）不在本地存储库中，则可能导致加载程序退出并获取远程存储库。
但是，我的理解是，尽管依赖关系图的动态构建是bazel的潜在未来方向，但当前执行不与分析混在一起，因此当执行开始时，完整的依赖树应该可用平淡无奇（因此已知的目标总数）？ bazel是否有完整的树，但只是不想遍历该树以防万一，如果它很大，还是在这里发生其他事情？
注意：我发现了对此现象here的简短提及，但没有解释为什么会发生这种情况。
答案 0 :(得分：2)
您在进度栏中看到的数字是指操作（命令行..ish）而不是目标（例如//my:target）。 I wrote a blog post关于动作图，这是关于它的相关描述：
操作图包含一组不同的信息：文件级 依赖项，完整的命令行以及Bazel需要的其他信息 执行构建。如果您熟悉Bazel的构建阶段， 动作图是加载和分析阶段的输出，用于 在执行阶段。
但是，Bazel不一定执行图中的每个动作。 它仅在必须执行时才执行，即动作图是超级 实际执行的操作的集合。
为什么分母不断增加，这是因为动作图中的动作执行发现是懒惰的。这是Bazel TL Ulf Adams的更好解释：
问题是Skyframe不会急于移动动作图， 但是它做得很懒。原因是性能，因为 动作图可能很大，以前是一个障碍 操作（Bazel会挂起一段时间）。缺点是 所有执行动作图的线程都会阻止他们执行的动作 执行，这会延迟发现其余操作。这就是为什么 数字在构建过程中不断增加。
来源：https://github.com/bazelbuild/bazel/issues/3582#issuecomment-329405311