终于写到第六篇了。如果你是从零开始跟着这个系列走，前面几篇已经把环境、源码、工具链都准备妥当，这一步就是让 GN 真正开始干活。生成构建文件这个动作看起来只是敲一条命令，实际却是整个 Chromium 编译流程中最关键的分水岭：参数选对了，后面跑 ninja 就是按部就班；参数选错了，后面每次编译都在为这一步的错误决定买单。这篇我会把 gn gen 的前置检查、参数含义、实操过程、常见报错和后续构建命令全部过一遍，尽量把踩过的坑一次说透。
这篇内容适合两类人：一类是第一次在 Windows 上编译 Chromium，前面已经被源码同步和工具链折腾到半放弃的；另一类是想把手头编译配置从“能跑”调成“跑得舒服”的。两种读者都应该能从这篇文章里找到自己需要的东西。
1. 生成构建文件之前，先确认这几项
这一步不是让你直接敲gn args就算完事。有几个前置条件如果不满足，GN 会报出各种看着莫名奇妙的错误，排查起来比看错误本身还痛苦。
1.1 环境变量与 depot_tools 路径检查
生成构建文件用的gn命令本身来自 depot_tools，所以第一步是确认depot_tools的路径已经写进 PATH。判断方法很简单：打开 cmd 或者 PowerShell，输入gn --version，如果输出版本号，ok；如果提示“gn 不是内部或外部命令”，那就是 PATH 有问题。
Windows 上有个特别容易踩的坑：环境变量改完之后，已经打开的终端窗口不会自动刷新。你明明刚在系统设置里把depot_tools加进 PATH，但当前终端里还是看不到。解决办法是重新开一个终端窗口，或者在 PowerShell 里手动执行一遍：
$env:Path = "C:\src\depot_tools;" + $env:Path注意路径换成你自己的实际位置。
另外要重点提醒一下DEPOT_TOOLS_WIN_TOOLCHAIN这个变量。它的作用有点反直觉：如果你在 Windows 上编译，并且想用本机安装的 Visual Studio 工具链，通常建议把它设为0，也就是明确告诉 Chromium 的自动化脚本：不要下载完整的工具链，直接用我本地装好的 VS。当年我在这里纠结了很久，脚本一直想联网拉工具链，但网络环境又不太好，后来才发现是缺少这个变量导致的。设为 0 之后，脚本会优先检测本机 VS 路径，生成速度也快一截。
set DEPOT_TOOLS_WIN_TOOLCHAIN=0这个变量建议永久写到用户环境变量里，避免每次编译前都手工设置。
1.2 源码版本与分支确认
如果你的源码是全新同步的，默认应该就在主干上。但如果你是想编译指定版本，比如 Chromium 145，那就确认一下当前的提交点是否在对应的发布分支上。
我的建议是不要直接用默认主干，因为这个系列既然写到 145 的编译，那你应该有明确的目标版本需求。切换分支的操作很简单：
git fetch --tags git checkout 145.0.xxx.yyy其中xxx.yyy换成你想编译的具体小版本号。这里有个细节：Chromium 的构建系统里，某些第三方依赖和 SDK 版本要求是绑定在特定版本上的，如果分支不对，gn gen阶段可能出现一些“找不到 xxx 工具链”的报错，实际解法不是配环境，而是先切到正确版本。
切完分支后，最好再跑一次gclient sync，把依赖库同步到和该版本匹配的状态。有些依赖不会自动跟着切换，不主动同步的话，后续生成构建文件时会有烦人的不一致报错。
1.3 本地编译工具链确认
Windows 上编译 Chromium 145，基本锁定 Visual Studio 2022，需要安装“使用 C++ 的桌面开发”工作负载，以及最新版本的 Windows SDK 组件。
GN 在生成构建文件时会自动扫描 VS 安装路径，如果找不到，会直接报错说Could not find a valid Visual Studio installation。与其报错后再查，不如提前用命令验证。打开 cmd，执行：
"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -latest -property installationPath如果能输出安装路径，说明检测没问题。如果没有输出，大概率是 VS 装得有问题，或者只有 Build Tools 没有完整 IDE 组件。
另外一个容易被忽略的点是“Windows SDK 版本”。Chromium 145 对 SDK 版本有最低要求，一般装最新的稳定版 Windows SDK 就能满足。如果你同时装了多个 SDK，GN 会自动选最新的，这个行为通常没问题。唯一要小心的是某个 SDK 组件损坏，会导致 GN 生成过程中出现诡异的文件访问错误，这种时候直接去 Visual Studio Installer 里修复安装，比手动改注册表快得多。
1.4 磁盘空间与内存的底线
生成构建文件本身占用的空间很小，但这里有个连带问题：gn gen过程中如果首次运行，可能会先进行工具链的自动部署，包括解压编译器包，此时磁盘空间不足的报错就出来了。
我自己实际遇到过一次：代码仓库在 D 盘，C 盘只剩 5GB，结果解压 clang 工具链到%LOCALAPPDATA%时撑爆了，报错信息还没直说“空间不足”，而是一堆文件校验失败，排查了很久才定位到是空间问题。
所以在跑gn gen之前，先确认两个位置的剩余空间：
- 源码所在的磁盘空间，建议预留 100GB 以上（因为后面构建产物也在这里）。
- C 盘系统盘空间，建议预留至少 15GB，工具链缓存可能落在用户目录。
内存方面，生成构建文件阶段要求不高，但如果你开启symbol_level = 2这类重符号参数，后面链接阶段的内存需求会暴涨。第一次先别开太狠，跑通再说。
2. gn gen 的工作逻辑与构建参数怎么选
很多教程直接扔给你一条gn gen out/Default就完了，很少解释为什么要这么写，以及这些参数背后的逻辑。这部分我会把 GN 的工作原理讲清楚，因为一旦你理解了它，后续所有参数调整都能自己判断。
2.1 GN 到底做了什么
GN（Generate Ninja）是 Chromium 构建系统的生成器，它本身不编译任何代码，它的任务是读取源码中的BUILD.gn文件，结合你提供的args.gn配置，最终生成一系列*.ninja文件。真正执行编译的是 Ninja，你可以粗浅地把 GN 理解成“设计院”，Ninja 是“施工队”。GN 给 Ninja 描绘出编译目标、依赖关系和具体命令，Ninja 按图施工。
之前我一直觉得这个生成过程应该是很快的，其实第一次跑它要解析上千个 BUILD.gn 文件，生成出几万个构建规则，不可能秒完。所以如果你看到首次gn gen卡了个几十秒到一两分钟，完全正常，不要以为是死机。
GN 生成的构建目录默认放在out/下，每个目录对应一套独立的构建配置。这一点非常实用，你可以有out/Default、out/Release、out/X64多个目录，互不干扰，想编译哪种配置就切哪种配置。
2.2 构建目录命名与路径陷阱
先说路径：构建目录一定不要放在有空格或者中文的路径下。Windows 下这是重灾区，C:\My Projects\chromium\src\out\Default这种路径会让 Ninja 工具链的各类脚本炸掉，报错信息千奇百怪，有说找不到文件的，有说路径解析失败的，实际上都是空格惹的祸。所以源码路径和构建路径最好都保持纯英文、无空格。
构建目录的命名主要靠约定。官方默认用out/Default，我个人的习惯是：
out/Default：日常开发调试版，组件化构建，链接快。out/Release：接近发行版配置，性能接近真实发布环境，偶尔跑测试用。
每个目录都是独立的，你在一套配置里瞎改参数不会影响另一套，很适合同时维护多版本需求。
2.3 一个能跑起来的最小 args.gn 配置
第一次生成构建文件，不要一上来就堆一堆高级参数，先拿一个保守配置跑通整个流程。下面这份配置是我实践过、在绝大多数 Windows 机器上都能稳定生成的模板：
# 调试模式，生成带调试信息的版本 is_debug = true # 组件化构建，模块编译成动态库，链接速度快 is_component_build = true # 符号级别，1 表示只生成必要符号，平衡调试和构建速度 symbol_level = 1 # 目标架构 target_cpu = "x64" # 去掉 Native Client 支持，减少编译规模 enable_nacl = false # 合并编译单元，降低编译时长（可选项） use_jumbo_build = true这四个参数的作用和取舍，我一个个说。
is_debug = true决定构建类型。调试模式下生成的二进制带完整调试信息，运行时检查和断言都会开启，非常适合开发和断点调试。缺点就是代码执行慢、体积大。如果你只是想验证“能不能编译成功”，其实开 debug 也没问题，后面真正要测性能再切 release。
is_component_build = true是日常开发的神器。它会把 Chromium 拆成大量 DLL 而不是一个大 EXE，这样每次改动源码后，Ninja 只需要重新链接改动的那几个模块，而不是把整个浏览器可执行文件重新推倒重来。我可以负责任地说，不开 component_build 的链接时间和开着的完全不是一个量级。首次构建反而会稍微慢一点（因为生成大量动态库），但之后就舒服了。
symbol_level = 1是很多教程不讲、但实操影响巨大的参数。完整符号（symbol_level = 2）在 Windows 上会导致链接阶段内存占用极高，动辄二三十 GB 内存，很多 16GB 内存的机器直接爆掉。设为 1 后，只会为动态库生成符号，静态文件符号会被裁剪，日常调试完全够用。如果你非要完整的函数调用栈，可以考虑对特定模块单独开高符号级别，而不是全局开启。
enable_nacl = false，这个纯粹是为了减少构建范围和同步体积，Chromium 的 Native Client 模块不是普通浏览器用户需要的，关掉不会影响浏览器功能，还能省不少编译时间。
use_jumbo_build = true的做法是把多个 C++ 源文件合并成一个编译单元，减少编译器进程启动次数。首次编译能节省不少时间，代价是某个文件报错时定位信息不准，以及增量编译时可能更容易触发部分模块的连带重编。不过总体收益大于成本，我一般都会开。
2.4 其他影响产出行为的参数
除了上面那套基础配置，还有几个参数根据你的实际需求选择，但不要一股脑加进去。
# 启用专利解码格式支持（H.264/AAC等） proprietary_codecs = true ffmpeg_branding = "Chrome"Chromium 官方版本是默认关闭 H.264/AAC 专利解码格式的，默认只带开源解码器。如果你要的是带 H.264/AAC 支持的版本，需要自己加这两行。注意ffmpeg_branding必须配合proprietary_codecs使用，单独写一个不会生效。编译出来的产物在功能上会更像日常使用的浏览器。
# 是否开启 Google 内部服务 / API 密钥 # google_api_key = "xxx" # google_default_client_id = "xxx"如果你想把同步、地图等功能完整跑起来，一般需要填入 API 密钥。但个人编译调试通常不需要，没有密钥也完全可以编译通过，只是某些功能会被禁用或报错。我建议首次先不加，等基本流程通了再研究。
记住一个原则：影响构建配置的参数会改变大量源文件的编译条件，一旦你在一个构建目录里改这些核心参数，很大概率触发一次大规模重编。所以最好是在第一次生成前想清楚，而不是生成之后又来回换。
3. 实操：生成构建文件的完整过程与关键细节
前置检查做完以后，这一节就是实际操作。我不会只扔个命令了事，会把过程中每一步的具体输出和人话解读都放上来，你照着走就行。
3.1 第一次运行 gn args
确认你已经cd到 Chromium 源码根目录（也就是包含src文件夹的目录），然后执行：
gn args out/Defaultgn args是一个组合命令：如果构建目录不存在，它会自动创建；如果args.gn不存在，它会弹出记事本让你编辑。第一次执行，记事本里大概是空的，把前面那套最小配置粘贴进去保存，关掉记事本后，GN 会自动开始生成构建文件。
这里有个小细节：如果你不喜欢让它在记事本里折腾，也可以手动创建args.gn文件，然后用gn gen替代：
# 手动创建 out/Default/args.gn 并写好参数后 gn gen out/Default两种方式效果一样，gn args只不过是先生成文件再调用gn gen的语法糖。比如在 CI 或者脚本化操作时，手动创建args.gn更可控。
3.2 首次生成时的输出长什么样
首次运行会有一大堆输出，大致是：
Running "gn gen" with "out/Default" args... Created new directory out\Default Loading... done. INFO: From gn gen (program): ERROR at //build/config/compiler/BUILD.gn:...看到ERROR不要慌，重点看前面两个字：INFO提示可能只是警告。正常的成功输出最后长这样：
Done. Made 254 targets from 105 files.这行字的意思是 GN 解析了 105 个 BUILD.gn 文件，生成了 254 个可构建目标。不同版本数字不同，但只要出现Done. Made xxx targets，就代表构建文件已经成功生成。
如果第一次跑出来有WARNING，多半是某些 target 是废弃的或者某参数被忽略，一般不影响使用。我自己的经验是只要最终状态是Done，就可以继续，别花时间纠结警告，后面真的跑起 ninja 时如果有问题会报得更加明确。
3.3 验证构建文件真的“能用”
生成结束不代表万事大吉，我习惯在开始长时间编译前先验证一下构建文件的完整性。最简单的方式是查看当前构建目录中的目标列表：
gn ls out/Default --type=executable如果输出里包含//chrome:chrome，说明浏览器主程序目标已经生成。如果想确认 ninja 是否能正确解析目标，还可以用：
ninja -C out/Default -t targets all | findstr chrome这个命令会列出所有包含 chrome 字样的构建目标，信息量巨大，但能看到就说明构建文件没有损坏。
这里有件事值得一提：生成的out/Default目录里有几个核心文件，不明白的作用不要手贱删除。
4. 生成过程中的常见问题与排查技巧实录
这部分我把过去这些年编译 Chromium 路上实际遇到过、以及身边人问得最多的生成阶段报错整理成速查表。遇到问题时优先来这里翻，比到处搜教程管用。
4.1 “gn” 不是内部或外部命令
这是最高频的问题，基本可以断定是 depot_tools 没进 PATH，或者是改完 PATH 后终端没重启。先确认depot_tools里的gn.bat确实存在，然后重新打开一个 cmd 窗口再试。如果你在 PowerShell 里跑，还有一个比较隐蔽的坑：PowerShell 执行策略可能阻止加载.bat，但这个在本地通常不会遇到，所以检查 PATH 是最优先的。
4.2 找不到 Visual Studio 安装
报错信息大致是：
ERROR: No Visual Studio installation found.这里先别急着卸载重装，按顺序排查：
- VS2022 是否装了“使用 C++ 的桌面开发”工作负载，只有这一个才带编译 Chromium 需要的工具链。
- 是否有
VC\Tools\MSVC目录，如果没有意味着 C++ 工具链没有安装。 DEPOT_TOOLS_WIN_TOOLCHAIN是否设成了 0，如果设成 1 或者没设，脚本会尝试走自动下载路线，容易碰到网络相关的问题。
其中DEPOT_TOOLS_WIN_TOOLCHAIN=0最值得确认，因为很多自动脚本默认会去拉取远程工具链，一旦拉取失败就报找不到 vs。设成 0 让脚本优先用本地，是我个人最推荐的 Windows 编译姿势。
4.3 Windows SDK 版本不受支持
报错有时会写成具体 SDK 版本号，例如：
The Windows SDK version 10.0.xxxxx.0 was not found.这个报错常在机器上装有多个 SDK 但最新版本不匹配时出现。解决方式是在 Visual Studio Installer 中安装“最新的 Windows SDK”组件。如果已经装了最新版但仍然报错，可能是 SDK 组件损坏，用 Installer 的“修复”功能处理，成功后重新跑gn gen。
4.4 gn gen 过程中磁盘空间不足
这个前面已经提过。一个比较隐蔽的现象是：报错发生在解压工具链的时候，而不一定是你源码所在的盘。因为工具链缓存经常落到%LOCALAPPDATA%，也就是 C 盘。如果你源码放在 D 盘而 C 盘空间紧张，照样会在gn gen时报错。
建议 C 盘和源码盘都看一眼剩余空间，C 盘至少预留 15~20GB，源码盘建议 100GB 以上。真遇到空间不足，我一般不开新盘，直接把仓库里不需要的.git历史文件做 GC 压缩，确实能腾出一点空间，但最稳的还是换个大点的盘存放整个工程。
4.5 gn gen 卡在某个检查步骤
很多新手会把正常的过程误认为卡死。比如生成过程中要检查工具链、解析超大量文件，界面可能几十秒没输出，这时不要狂按 Ctrl+C。我给自己的一个参考时间是：如果没有任何报错且 CPU 有波动，就说明在干活；如果持续三五分钟毫无反应，可以考虑网络侧的问题，因为某些依赖检查需要访问远端。解决方式不是中断，而是检查网络环境后再重跑，一般第二次很快就过。
4.6 修改参数后没有生效
那就是args.gn没改对。改完参数后重新生成的方式有两种，效果不同：
gn args out/Default这会打开编辑器直接编辑args.gn，保存后自动重跑gn gen。
gn gen out/Default这会按现有args.gn重新生成，不会弹编辑器。
在验证参数是否生效时，可以用：
gn args out/Default --list --short这个命令会输出当前所有生效参数，内容很长，建议配合findstr过滤，例如：
gn args out/Default --list --short | findstr "symbol_level"只要输出里有symbol_level = 1就说明已经生效。
5. 构建文件生成后的下一步与日常迭代心得
生成构建文件本身不是终点，它只是开始。这一节除了给出最终构建命令，我还想聊聊如何从这一步开始规划日常的编译流程，避免每次编译都像第一次一样痛苦。
5.1 用 autoninja 拉起第一次构建
构建文件就绪后，不要直接敲ninja -C out/Default chrome，更推荐用：
autoninja -C out/Default chromeautoninja是 depot_tools 自带的封装工具，它会自动计算机器可用的并行任务数，并为 Ninja 设置合理的并发参数。Chromium 这种体量的项目，并发数太少会慢到怀疑人生，并发数拉太高又可能把内存干爆。让自动脚本去判断，是最稳妥的做法。
第一次构建耗时很长，取决于你的 CPU 核心数和磁盘类型，从一小时到三四小时都有可能。硬件一般的机器建议保证没人打扰的时候再开始。过程中不要随意关机或强制中断，万一中断了也不用删目录，重新跑autoninja会接着之前的进度继续，Ninja 的增量能力比很多人想象中强得多。
5.2 构建过程中看什么、等什么
第一次构建信息滚动得很快，经常有人问我怎么判断是否正常。我的方法是看两个信号：
- 有没有出现
FAILED:字样，如果出现，这一行后面就是具体报错命令。 - 有没有
ninja: build stopped: subcommand failed.，这就意味着构建失败。
如果只是看到很多cc和link输出滚动，没有FAILED，那就说明一切顺利。第一次构建很容易遇到前几个文件编译报错的情况，因为很多依赖关系到这一步才真正被编译。常见原因不外乎磁盘空间不足、杀毒软件误删中间文件、内存不够导致编译器崩溃。
杀毒软件这个东西特别值得单独拎出来说。Windows 上的实时防护对编译影响超出预期，它会在编译过程中反复扫描大量临时文件，明显拖慢构建速度，甚至有时把正在写入的中间产物判定为可疑文件直接隔离掉，导致构建失败。我个人的习惯是把源码目录、out 目录以及 depot_tools 目录都加入杀毒软件排除列表。这一步对构建稳定性的提升非常明显。
5.3 日常增量构建的经验
构建文件生成后最大的甜点就是增量编译。组件化构建模式下，正常改动一个源文件后再次构建，几十秒到几分钟就能出结果。你会看到 ninja 不再编译整个项目，而是只处理改动过的模块然后链接。这种节奏才是 Chromium 开发的常态。
有个非常关键的日常操作技巧：如果你只是改了一两个模块想快速验证，不建议改args.gn中的大参数，例如把is_debug从 true 改成 false，这会把几乎所有源文件的编译条件都改变，导致全量重编，等于把之前的心血清零。想要切换配置，应该在新建的构建目录里进行，保留现有目录不动。
另外，如果你想在多个配置之间频繁切换，那么先养成为每个配置建立单独构建目录的习惯。我目前的布局一般是：
out/DebugFast：日常开发，组件化、低符号。out/Release：性能测试，非组件化、高优化。out/Profile：带性能剖析符号的版本。
每个目录单独生成构建文件，互不干扰，按需切换。刚开始不需要这么多，但保持“一套配置一个目录”的思路会让你省掉很多无意义的全量重编。
5.4 关于编译团队效率的两个额外建议
如果你是在团队中协作，大家共用同一台编译服务器，或者想进一步缩短本机构建时间，可以考虑给构建过程加一层编译缓存。Windows 上搭配sccache是比较成熟的方案，核心原理是把编译产物缓存下来，重复编译相同版本时直接复用，避免重复劳动。配置 sccache 属于另一个话题，但前提是构建文件里正确打开了 depfile 和 compiler 相关配置，而gn gen默认就是支持的，这也是为什么我建议生成构建文件这一步不要随意裁剪参数的原因。
如果是个人本地编译，比起配置缓存，更明显的收益来自物理硬件升级——CPU核心数、NVMe固态、大容量内存。这听起来像废话，但 Chromium 构建对这三项的敏感度远超普通项目。之前我在一台 8 核笔记本上首次构建跑了三个半小时，换到 16 核台式机后压到不到一小时，差距就是这么大。
最后分享一个我实际踩过的取舍问题。第一次编译时，我为了拿到完整的代码调试体验，直接把symbol_level拉到了 2，结果链接阶段内存占用直接顶满，系统濒临假死。后来把级别降回 1，才发现日常断点和调试根本不受影响，链接时间却降了一个量级。所以如果你是第一次用这套流程，建议就按照默认的保守配置跑通一遍，确认产物能正常打开、能进 DevTools、能在 VS 里下断点，之后再去逐个研究参数调整的效果。Chromium 的构建系统非常透明，你每个参数改完都能直接看到对构建时间和产物体积的影响，但这种观察的前提是先有一个完全跑通的基线。这条路径走通了，后面所有优化才有的放矢。
