Chromium 源码构建：depot_tools、GN、Ninja 与增量编译

归档与更新说明： 本文归入 2018 年 Chromium 二次开发专题，并于 2026-09-28 重新整理。Chromium 的分支、构建参数和依赖变化很快，实际操作请同时核对对应版本的官方文档与源码。

Chromium 构建链路通常由 depot_tools、gclient、GN 和 Ninja 组成。不同平台的依赖安装方式不同，但整体思路一致：获取受控版本的源码与依赖，生成构建目录，再由 Ninja 执行编译。

目录与工具链

• depot_tools 提供 fetch、gclient、autoninja 等工具。
• gclient 根据 DEPS 同步 Chromium 及第三方依赖。
• GN 把 BUILD.gn 描述转换成 Ninja 构建文件。
• autoninja/Ninja 根据依赖图执行并行和增量构建。

典型流程的形态如下，具体命令应以目标分支文档为准：

fetch chromium
gclient sync
gn gen out/Default
autoninja -C out/Default chrome

从最小参数开始

不要一开始复制一份来源不明的巨大 args.gn。先用接近默认值的配置完成构建，再逐项加入品牌、编解码器、符号级别或组件构建参数。

is_debug = false
symbol_level = 1

每增加一个参数，都应记录它解决的问题、支持的平台和验证方法。GN 参数会随版本变化，使用前可通过 gn args out/Default --list 查看当前源码支持的选项。

构建稳定性的关键

1. 固定源码 revision，不直接把“今天的 main”当作可发布版本。
2. 将源码缓存、构建产物和发布产物分开管理。
3. 记录操作系统、编译器、SDK 和 depot_tools 版本。
4. CI 中从干净环境定期重建，避免只依赖开发机的增量状态。
5. 内存不足时减少并行度，不要让 OOM 产生难以解释的随机失败。

常见故障

gclient sync 失败通常与网络、磁盘、Git 状态或依赖脚本有关；链接阶段失败常见于内存不足或参数组合不兼容；“本机能编译、CI 不能”则往往说明环境没有被完整记录。

官方平台说明：Linux 构建、Windows 构建。