Buck2 首先是构建守护进程，其次才是更快的 Buck

封面使用一张真实的 Wikimedia Foundation 服务器机房照片。它适合 Buck2，是因为本文讨论的是如何让构建工作在守护进程状态、缓存和远程执行之间复用，而不是让每台开发者机器独自重新发现整张图。[9]

Buck2 很容易被概括成“Meta 用 Rust 重写 Buck，并把它做得更快”。这句话足够好记，也基本属实，但会遮住它的架构。更有用的读法，是把 Buck2 看成一种构建系统：它把工作移入长期运行的守护进程，评估一层与语言无关的 Starlark 规则，并试图把构建图刻画到足够精确，让本地迭代、远程执行和多语言 monorepo 工作都能共享同一份契约。[1][2][4]

这一区分直接影响采用方式。团队不能只把一个命令名换成另一个命令名，就得到 Buck2 的价值。它必须接受这套模型：BUCK 文件划出 package 边界，target 组成无环图，规则声明 action 和 provider，守护进程则在两次命令之间保留足够多的项目状态，让重复工作变得便宜。[3][4][5] 因此，Buck2 不是一个即插即用的加速技巧。它押注的是图的形状、规则的清晰度和执行结果的复用。

截至 2026-06-24T21:34:20Z UTC，GitHub API 报告 facebook/buck2 有 4,364 个 star、366 个 fork、380 个 open issue，最近一次 push 时间为 2026-06-24T20:09:35Z；release feed 显示了带日期的版本，包括 2026-06-15、2026-06-01、2026-05-18 和 2026-05-01，而特殊的 latest 标签仍然对应滚动二进制渠道，并非传统意义上的稳定版本。[7][8] Meta 2023 年的发布文章给出了这次重写背后的规模背景：数千名内部开发者、每天数百万次构建，以及观察到的内部构建速度达到 Buck1 的两倍。[11] 这些数字不能证明 Buck2 适合某个具体组织。它们表明，这是一个活跃项目，同时它的公开使用面仍要求用户理解成熟度边界。

图片背景：头图不是 logo、图表，也不是生成的构建示意图。它是一张真实的服务器机房照片，之所以使用它，是因为 Buck2 最有意思的主张只有在构建工作被当作基础设施时才会显现：守护进程状态、action digest、内容寻址 artifact 和远程执行，都依赖多台机器对一次构建 action 的含义达成一致。[4][6][9]

守护进程是第一道边界

Buck2 的守护进程 buckd 会在某个项目第一次运行 Buck2 命令时启动。后续命令会检查正在运行的守护进程，并用它来执行工作，由此让 Buck2 在多次调用之间共享缓存状态。[5] 默认情况下，每个项目根目录对应一个守护进程；当项目需要多条相互隔离的守护进程通道时，也可以使用 isolation directory。[5] 这是理解 Buck2 的第一点：它不只是一个每次从头解析仓库的命令行程序。它是一个客户端，正在与一个项目范围内的服务通信。

架构页面把这种 client/server 形态写得很清楚。Buck2 CLI 在客户端进程中运行，通过 gRPC 把命令发给守护进程；随后守护进程进入 evaluation、configuration、analysis、execution 和 materialization 等阶段，buck2 test 还会增加 testing 阶段。[4] 同一页面也提醒，这些阶段并不总是严格按顺序推进，因为 Buck2 围绕一张更大的依赖图设计，增量性在其中占据核心位置。[4]

这会改变人们理解构建失败的方式。在 make 式心智模型里，主要问题通常是“运行了哪个命令”和“哪个文件变了”。到了 Buck2，问题会变得更具体：守护进程有没有观察到相关文件系统变化，evaluation 有没有产出预期的未配置 target graph，configuration 有没有选择正确平台，analysis 有没有声明正确的 action 和 provider，execution 有没有复用或运行正确的 action。失败表面被拆成更清楚的层次。这个层次本身就是设计目标。

代价也随之出现。只要有守护进程，生命周期行为就会变得重要。Buck2 把 buck2 status、buck2 clean 和 buck2 kill 作为检查或重置守护进程状态的常规工具来说明。[5] 采用 Buck2 的团队，应当把这些命令纳入支持与排障的肌肉记忆，而不是把守护进程当成看不见的背景。当构建状态长期存在时，重置和检查路径就是产品的一部分。

Package、Cell 和 Project 防止 Monorepo 变成一团

Buck2 的关键概念页面给这套构建模型提供了词汇。build rule 描述如何从输入生成输出。build target 是标识某条规则的唯一字符串。build file 通常名为 BUCK，定义一条或多条规则。[3] package 由 BUCK 文件创建：一个 package 包含 build file 所在目录及其子目录，直到另一个 BUCK 文件创建新的 package 边界。[3] 这种互不重叠的关系不只是命名纪律。它防止所有权和图发现退化成一次没有上限的目录遍历。

cell 添加了仓库规模上的一层。cell 是一个目录树，包含一个或多个 Buck2 package，并通过 .buckconfig 配置；project 是一次构建的入口，并命名所涉及的 cell。[3] 文档指出，cell 经常对应仓库，但二者没有必然绑定。[3] 这个保留很重要。Buck2 是为 monorepo 设计的，但抽象并不等于“一个 repo 就是一个世界”。它允许 project 有意识地定义构建宇宙。

随后，target graph 会把这些边界连起来。Buck2 要求依赖图无环；传递依赖会先于需要它们的 target 构建，文档也明确指出，这种自底向上的关系有助于 Buck2 识别彼此独立的子图和最小重建集合。[3] 这就是采用 Buck2 的核心要求：团队必须写入足够多的依赖事实，让图真正有用。如果 package 边界松散，依赖又藏在脚本后面，Buck2 继承的是混乱，而不是治愈混乱。

当一个 monorepo 里有许多语言和许多交付物时，收益才会显现。Meta 的“Why Buck2?”页面把最初的问题描述为一个非常大的 monorepo，横跨 C++、Python、Rust、Kotlin、Swift、Objective-C、Haskell、OCaml 等语言。[2] 传统构建脚本可以在一段时间内协调其中一部分工作。可当一次变更需要同时回答影响范围、测试选择、远程执行和跨语言依赖问题时，它们就会吃力。Buck2 的 package/cell/project 词汇，是提出这些问题的脚手架，避免把整个仓库压成一个没有差别的构建 target。

Starlark 规则把语言知识移出核心

Buck2 最重要的设计选择，也许是一个反向选择：核心二进制与语言无关。README 表示，Buck2 的核心二进制不知道特定语言规则；“Why Buck2?”页面也说，所有规则都用 Starlark 编写，区别于 Buck1 把规则放在 Java 核心里的模型。[1][2] 架构页面写道，macro 和 rule 都用 Starlark 编写，而 Rust 核心负责 CLI 执行、图生成与更新、依赖图计算和 artifact materialization。[4]

这个拆分说明，评估 Buck2 时不应只看内置语言支持的清单。它的设计要求规则作者在 Starlark 层明确表达语言行为。规则编写文档把流程说得很直接：一条规则使用 attribute 声明 action，action 产出 artifact，provider 是一条规则向依赖它的规则暴露信息的唯一方式。[6] 每条规则至少必须返回 DefaultInfo；能运行的规则可以返回 RunInfo；更丰富的语言集成会定义自定义 provider，在图中传递信息。[6]

这个 provider 边界是真正的架构边界。如果一条 Python 规则依赖一个 Rust 库，或者一个 OCaml target 需要生成出来的 C artifact，交接过程不能是藏在 shell 脚本里的副作用。规则必须决定哪些信息向外流动。做得好，构建图就能被查询，也能被复用。做得差，它只是在同样隐藏的状态外面包了一层更复杂的外壳。

Buck2 的高级规则能力显示了 Meta 为什么选择重建，而不是只打磨 Buck1。“Why Buck2?”页面点名了 dep file、incremental action、dynamic dependency、anonymous target、接入依赖图的 transitive set，以及没有僵硬的 target graph/action graph 阶段切分。[2] 这些都不是入门功能。它们存在，是因为大型构建需要表达更细的现实：生成后的依赖发现、原本无关输出之间共享工作、很深的传递闭包，以及简单静态图很难干净刻画的 action 复用。

采用时的提醒也由此直接得出。团队起步时不应先写聪明的 Starlark。它应当先选择构建中一块很小、很痛、规则边界已经清楚的部分：一个语言 target、一条生成代码路径、一个测试 target，或者一个跨语言依赖。只有普通图值得信任之后，Buck2 的灵活性才真正有价值。

远程执行是一份契约，不是一个按钮

Buck2 明确面向远程执行。README 表示，Buck2 可以通过 Bazel 同样支持的 Remote Execution API 使用分布式编译，并点名 BuildBarn、BuildBuddy、EngFlow 和 NativeLink 这些兼容方案。[1] 远程执行文档说，Buck2 可以使用暴露 Bazel remote execution API 的服务，并列出 engine address、action-cache address、CAS address、TLS material、header、instance name 和 digest algorithm 等配置键。[10]

架构页面给出了具体机制。在 execution 阶段，Buck2 会根据某个 action 的命令及其全部输入创建 digest，检查远程执行侧是否已有缓存结果，然后复用结果，或者在本地或远程运行该 action。远程执行会把输出存入 content-addressable store；materialization 可以立即发生，也可以推迟到需要时再发生。[4] 图在这里变成基础设施。只有 action digest 如实捕捉了决定输出的命令和输入，缓存命中才可信。

这也是 Buck2 的 hermeticity 表述必须细读的原因。README 说，Buck2 在使用远程执行时会变成 hermetic，因为构建规则必须正确声明输入；它也说明，仅在本地运行的构建步骤当时还没有以同样方式 sandbox。[1] 实际含义并不是“远程执行只是可选加速”。更接近的是：“远程执行是更严格正确性契约出现的地方。” 只在本地试点，可以帮助团队学习规则模型和开发者体验，但完整架构指向的是兼容远程执行的 action。

对于已经运行 Bazel 式远程执行的组织，Buck2 的兼容性叙述会减少一类基础设施风险。它不会消除迁移工作。你仍然需要 execution platform、toolchain packaging、认证、action-cache 与 CAS 容量规划、网络行为，以及哪些 action 可以远程运行的策略。[10] 如果这些环节含糊，Buck2 很快就会把含糊暴露出来。

Buck2 适合放在哪里

Buck2 在三项条件同时成立时最有力量。第一，仓库大到重复的本地发现和大范围重建已经很昂贵。第二，语言组合复杂到临时脚本会让依赖事实难以看清。第三，组织愿意拥有构建基础设施：守护进程生命周期、Starlark 规则维护、toolchain packaging、远程执行和图调试。[1][2][4][10]

当仓库规模小、语言单一，并且已经被该语言的原生构建工具很好覆盖时，Buck2 的优势会减弱。在这种环境里，Buck2 的 package/cell/project 模型、守护进程状态、Starlark 规则层和远程执行路径都会变成额外机器。README 坦率说明，Buck2 面向外部使用者仍有粗糙之处，没有传统稳定版本标签，Meta 内部使用的是最新提交的 HEAD。[1] 谨慎的外部团队应当把这视为采用边界，而不是脚注。

健康的试点应该窄而可衡量。选择一条当前系统浪费开发者时间或隐藏依赖事实的构建路径。用 BUCK 文件建模 target 及其依赖。把规则编写保持在最低限度。先在本地运行，理解守护进程行为和图输出。等到 action 诚实声明输入和输出后，再测试远程执行。目标不是证明 Buck2 在演示中更快。目标是证明构建可以变得更可检查、更可复用，也更少依赖单台工作站状态。

当守护进程、图、规则边界和远程执行契约互相加强时，Buck2 才赢得位置。如果团队只想要一个更快的命令，它多半会失望。如果它需要一个构建系统，让一个大型多语言仓库表现得像一项可查询、可缓存、可分布执行的计算，Buck2 值得认真评估。

cronfeed.work