Jonathan Lange 写了一篇关于 Bazel 如何缓存测试的 精彩博文 。基本上：如果你运行一个测试，改变你的代码，然后再次运行一个测试，只有当你改变了一些可能真正改变测试结果的东西时，测试才会重新运行。 Bazel 在很大程度上采用了这个概念来最大限度地减少您的构建需要做的工作，在某些方面并不是很明显。
让我们举个例子。假设您正在使用 Bazel 来“构建”rigatoni arrabiata，它可以表示为具有以下依赖项：
每种食物都是一个图书馆，它依赖于它下面的图书馆。假设你改变了一个依赖，比如大蒜：
Bazel 会统计“garlic”库的文件并注意到这个变化，然后记录下依赖“garlic”的东西可能也发生了变化：
这个奇特的术语是构建图的“使向上传递闭包无效”，也就是“依赖于事物的一切都可能是脏的”。请注意，Bazel 已经知道此更改不会影响几个库（通心粉、番茄泥和红辣椒），因此绝对不必重建它们。
然后 Bazel 将评估“sauce”节点并确定其输出是否已更改。这就是秘诀（哈！）发生的地方：如果“sauce”节点的输出没有改变，Bazel 知道它不必重新编译 rigatoni-arrabiata（顶级节点），因为它的直接依赖关系改变了！
sauce 节点不再“可能是脏的”，因此它的反向依赖项 (rigatoni-arrabiata) 也可以标记为干净的。
一般来说，当然，更改库的代码会更改其编译形式，因此“可能脏”节点最终将被标记为“是，脏”并重新评估（依此类推树）。但是，Bazel 的构建图允许您编译结构良好的库的最低限度，并且在某些情况下完全避免编译。