Bazel 9.3.0 介绍与选型指南

目标：从官方一手资料出发，讲清 Bazel 是什么、核心架构与功能特性、适用与不适用场景，并以量化维度完成与 Make/CMake、Buck2、Pants、Gradle 的选型对比。本篇为认知篇，全部内容基于官方文档与官方发行渠道联网溯源，不含本地实测内容；所有来源均标注查询日期 2026-10-20。

一、资料来源与查询环境

本篇不依赖本地安装实验，全部结论均溯源至下列一手来源，溯源动作均在 2026-10-20 完成：

💡 说明：为规避 GitHub API 限流，星数与贡献者数均通过 shields.io 徽章接口取证；版本清单通过 Releases Atom 流取证，二者均不触碰 api.github.com。

二、软件概述

2.1 Bazel 是什么

Bazel 是 Google 开源的多语言构建与测试工具，官方 FAQ 对其的一句话定义是：「Bazel is a tool that automates software builds and tests」（Bazel 是一个自动化软件构建与测试的工具），支持的构建任务包括运行编译器与链接器、组装部署包、运行测试套件等（来源：bazel.build/about/faq，查询日期 2026-10-20）。

几个关键身份信息：

2.2 当前版本格局（2026-10-20 实查）

通过官方 Releases Atom 流逐条核对（查询日期 2026-10-20），Bazel 当前版本格局如下：

Release Atom 流最近 10 条记录覆盖 2026-09-22 至 2026-10-14 约 22 天窗口，期间有正式版、RC 与滚动预发布交替出现，发布节奏非常活跃。

💡 技术拓展：Bazel 的版本体系不止「稳定版」一种。按官方版本策略（bazel.build/release/versioning，查询日期 2026-10-20），Bazel 采用 major.minor.patch 语义化版本，每个 major 版本就是一个 LTS 版本；除此之外还有以日期命名的滚动预发布（如 10.0.0-pre.20261006.3）。每个 major 版本有四个支持阶段：

阶段	含义
Rolling	该 major 尚在预发布期，团队从主干持续发布滚动版本
Active	当前活跃 LTS，minor 版本会回迁重要特性与缺陷修复
Maintenance	旧 LTS 进入维护期，只回迁安全类与操作系统兼容类关键修复
Deprecated	不再提供支持

按此策略，9.x 处于 Active 阶段、8.x 已进入 Maintenance——生产环境选型应以 9.x 为主线。

2.3 与同类工具的官方定位

官方 FAQ 对同类工具给出了明确的定位语：「Bazel is similar to other tools like Make, Ant, Gradle, Buck, Pants and Maven」（Bazel 与 Make、Ant、Gradle、Buck、Pants、Maven 等工具相似），随后列举了它的差异化特性（来源：bazel.build/about/faq，查询日期 2026-10-20）：

• 多语言支持：官方原生覆盖 C++/Java/Python/Android/iOS 等场景，并可通过规则扩展支持任意语言；
• 高层构建语言：项目以 BUILD 文件描述——一种精简的文本格式（即 Starlark 方言）；
• 可测试性：Bazel 的测试语义（目标规模、数据依赖、超时）内建于构建模型；
• 增量与正确性：基于精确依赖图的失效与重构建，而非文件时间戳；
• 规模化设计：源自 Google 内部超大规模 monorepo 的实践。

三、核心架构

以下概念体系来自官方文档（bazel.build 的 Concepts & terminology 与 User guide 部分，查询日期 2026-10-20）：

3.1 工作区与包：三级目标模型

• 工作区（Workspace）：一个含有 MODULE.bazel（新机制）或 WORKSPACE（旧机制）标记文件的目录树根，是 Bazel 的构建边界；MODULE.bazel 是 Bazel 7 起默认开启的 Bzlmod 依赖管理机制的入口。
• 包（Package）：工作区内每个含 BUILD（或 BUILD.bazel）文件的目录构成一个包。
• 目标（Target）：包内声明的构建单元，包括规则目标（rule，如 cc_binary、java_library）与文件目标（源文件、生成文件）。目标用标签（label）寻址，形如 //path/to/package:target_name。

3.2 动作图与执行模型

Bazel 将构建过程建模为动作图（action graph）：每个目标经分析（analysis）阶段展开为一组动作（action，如一次编译、一次链接），动作声明「输入 → 输出」的确定映射。执行阶段自底向上运行动作，并依托四层缓存实现增量与共享：

3.3 客户端-服务器进程模型

Bazel 是持久的客户端-服务器架构：bazel 客户端命令把请求交给一个常驻的 JVM 服务器进程执行，服务器在多次构建间保持分析缓存。这一模型带来的直接体验是：工作区内的第二次构建通常在亚秒级完成（服务器复用已装载的包与分析结果）；副作用是每个工作区各占用一段常驻内存，需用 bazel shutdown 显式回收。

3.4 依赖管理：Bzlmod

Bazel 7 起默认启用 Bzlmod 模块化依赖管理：依赖以 bazel_dep() 声明在 MODULE.bazel 中，从 Bazel 中央注册库（Bazel Central Registry，bcr.bazel.build）解析版本；旧 WORKSPACE 机制仍兼容但已非默认。官方 Ubuntu 安装文档亦明确了平台边界：APT 仓库不含 arm64 版本，Arm 平台应使用 Bazelisk 或源码编译（来源：bazel.build/install/ubuntu，查询日期 2026-10-20）。

四、功能特性

综合官方文档（bazel.build 各特性页，查询日期 2026-10-20），Bazel 的核心特性可归纳为七项：

1. 多语言构建：官方规则覆盖 C++、Java、Python、Android、iOS 等；社区规则库（如 rules_rust、rules_go）经 BCR 分发，扩展任意语言只需编写 Starlark 规则。
2. 正确的增量构建：依赖图驱动失效——只重建真正受影响的动作，且以内容与配置指纹判定而非文件时间戳。
3. 多级缓存与远程执行：本地动作缓存、磁盘缓存、仓库缓存叠加 Remote Execution API（远程缓存/远程执行），是大型团队 CI 提速的主要杠杆。
4. 内建测试框架：bazel test 统一执行测试目标，内建测试规模（small/medium/large/enormous）、超时、标签过滤、flaky 重试与覆盖率（bazel coverage）支持。
5. 查询能力：query/cquery/aquery 三个层次分别查询目标依赖图、带配置的目标图与动作图，可脚本化分析构建结构。
6. 可重现构建（Hermeticity）：动作要求封闭输入输出，配合工具链（toolchain）抽象与平台约束（platforms），同一输入在不同机器产生一致输出。
7. Starlark 可扩展性：BUILD/*.bzl 使用 Starlark 语言（Python 方言），宏、规则、仓库规则、工具链均可用其编写。

五、快速开始（最小可用示例）

本节内容整理自官方文档（bazel.build/install 与 bazel.build/start/cpp，查询日期 2026-10-20），仅给出官方流程与命令形态；各命令的完整实测回显见本专栏安装篇与命令篇。

5.1 安装

官方对 Ubuntu 平台的推荐安装方式是 Bazelisk（版本管理器），官方 APT 仓库为备选（来源：bazel.build/install/ubuntu，查询日期 2026-10-20）：

# 官方推荐：Bazelisk（自动跟随项目的 .bazelversion）
# 二进制或 npm 方式安装，详见 bazel.build/install

# 备选：官方 APT 仓库（amd64）
sudo apt install apt-transport-https curl gnupg -y
curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg
sudo mv bazel-archive-keyring.gpg /usr/share/keyrings
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/bazel-archive-keyring.gpg] https://storage.googleapis.com/bazel-apt stable jdk1.8" | sudo tee /etc/apt/sources.list.d/bazel.list
sudo apt update && sudo apt install bazel

官方文档特别说明：源配置中的组件名 jdk1.8 仅为历史兼容保留，与 Bazel 实际依赖的 Java 版本无关——Bazel 发布包自带私有 JRE，运行 Bazel 本身不需要安装任何 Java（如需构建 Java 代码才需另装 JDK）（来源：bazel.build/install/ubuntu，查询日期 2026-10-20）。

5.2 最小 C++ 工程（官方教程形态）

官方 C++ 教程（bazel.build/start/cpp）的最小工程由四个文件构成：

mkdir -p main-project && cd main-project

工作区根放 MODULE.bazel（声明模块名，Bzlmod 入口）：

module(
    name = "my_project",
    version = "0.1.0",
)

同目录放 BUILD 文件（声明一个 cc_binary 目标）：

cc_binary(
    name = "hello-world",
    srcs = ["hello-world.cc"],
)

再放源文件 hello-world.cc，随后执行构建与运行：

bazel build //:hello-world   # 构建目标，产物位于 bazel-bin/
bazel-bin/hello-world        # 直接运行构建产物

💡 技术拓展：BUILD 文件里的 cc_library/cc_binary 在 Bazel 8 之后不再是「内置原生规则」——需要显式 load("@rules_cc//cc:cc_library.bzl", "cc_library") 加载，且 @rules_cc 仓库需要在 MODULE.bazel 里以 bazel_dep(name = "rules_cc", version = "...") 声明。这是从旧教材/旧项目迁移到 Bazel 8/9 时最高频的踩坑点之一（官方规则库 rules_cc 已迁移至 BCR 分发）。

六、适用场景与限制

6.1 适用场景

结合官方 FAQ「Why would I want to use Bazel?」「What is Bazel best at?」章节（查询日期 2026-10-20）与上述特性，Bazel 的最佳适用面为：

• Monorepo / 多语言大仓：单一仓库内混合 C++、Java、Python、Go、Rust 等技术栈，需要统一构建入口与精确跨语言依赖；
• 大规模代码库的增量构建：全量构建以十分钟计的仓库，依赖图的精确失效 + 缓存能带来数量级的提速；
• 对 CI 时长敏感的团队：远程缓存/远程执行把同一动作的产物在全团队复用；
• 要求可重现构建的交付：封闭动作 + 工具链抽象，产出可复现的二进制与部署包。

6.2 不适用场景与成本

官方 FAQ「What should I not use Bazel for?」明确提示：Bazel 并非对所有项目都是正确选择。结合官方论述，主要成本与限制为：

• 小项目收益有限：小代码库全量构建本来就快，建立 BUILD 文件体系与规则学习的固定成本难以摊薄；
• 规则覆盖是前置条件：使用非官方原生支持的语言/框架时，取决于社区规则成熟度（如 《Rust 1.99 介绍与选型指南》中的 Cargo 对 Rust 生态而言就是开箱即用的官方构建器，无需引入 Bazel）；
• IDE 体验需额外集成：需借助 IntelliJ Bazel 插件等工具桥接，纯 IDE 一键体验弱于语言官方构建器；
• 习惯迁移成本：Makefile/CMake/脚本式构建的团队需要重建构建描述与开发者习惯。

七、同类选型对比（量化）

7.1 社区活跃度与版本节奏（全部数据标注来源与查询日期 2026-10-20）

表内 Stars 均取自 shields.io GitHub Stars 徽章接口、版本号均取自各官方仓库 Releases Atom 流，查询日期统一为 2026-10-20。关键解读：Bazel 在同类通用构建工具中社区规模最大且 LTS/维护双线节奏稳定；Buck2 采用日期化发布，适合追新的团队，但版本策略上不如 LTS 线直观；Pants 社区规模最小但聚焦 Python monorepo 场景。

7.2 横向能力对比

💡 说明：本表为选型导向的定性对比，事实性表述综合自各工具官方文档；「远程执行」一行的能力差异以各官方文档功能描述为准（查询日期 2026-10-20）。

7.3 选型建议（「如果…则…」）

• 如果是 C/C++ 为主、构建链已成熟的中小项目 → 留在 CMake/Make 体系；引入 Bazel 的收益难以覆盖迁移成本。
• 如果是 JVM 单生态项目 → Gradle 是生态默认；Bazel 仅在「JVM + 其他语言混合大仓」时纳入考虑。
• 如果是多语言 monorepo、构建时长已成为 CI 瓶颈、且团队有一定工程化投入意愿 → Bazel 与 Buck2 二选一：需要成熟 LTS 版本策略与最大社区基数选 Bazel；认同远程执行优先、可接受日期化版本节奏的选 Buck2（其 Starlark 方言与 Bazel 兼容，未来迁移成本相对可控）。
• 如果是 Python 为主的 monorepo，希望「少写 BUILD 细节」 → 可评估 Pants（依赖自动推断路线）；Bazel 则是显式声明的路线。
• 如果是单个语言项目（如纯 Rust、纯 Python） → 优先语言官方构建器（如 Cargo、pip/uv 体系，见 《Rust 1.99 介绍与选型指南》、《Python 3.15 介绍与选型指南》），它们与语言生态的耦合最深、上手最快。

7.4 在 CI 与发行版环境中的位置

Bazel 不提供 Web 界面与常驻服务，在交付链中的位置是构建执行引擎：上游由代码托管与 CI 系统触发（如在 CI 平台中调用 bazel build/bazel test，自托管 CI 的部署与运维可参考 《Woodpecker CI v3.19.0 介绍与选型指南》），下游产出二进制/镜像/部署包。运行环境方面，官方明确支持 Ubuntu 22.04/20.04/18.04 LTS（查询日期 2026-10-20，来源 bazel.build/install/ubuntu）；Ubuntu 系统下通过 APT 仓库安装时依赖系统包管理基础，相关命令体系见 《Ubuntu 24.04 apt 包管理工具命令详解》。

八、参考链接

1. 官方文档首页：https://bazel.build
2. 官方 FAQ（定位与限制论述）：https://bazel.build/about/faq（查询日期 2026-10-20）
3. 官方版本策略（LTS 支持阶段）：https://bazel.build/release/versioning（查询日期 2026-10-20）
4. 官方 Ubuntu 安装文档：https://bazel.build/install/ubuntu（查询日期 2026-10-20）
5. GitHub 仓库：https://github.com/bazelbuild/bazel（许可证与版本信息取证，2026-10-20）
6. Releases Atom 流：https://github.com/bazelbuild/bazel/releases.atom（版本节奏取证，2026-10-20）
7. Bazelisk 官方 README：https://github.com/bazelbuild/bazelisk（版本锁定机制，2026-10-20 经 npm 源核对）
8. Bazel 中央注册库：https://bcr.bazel.build