macOS上编译Chromium 144：环境准备与避坑指南

Chromium 144 的源码我前前后后拉了两遍，第一次因为磁盘规划没做对，编译到一半直接把系统分区撑爆了，Xcode 版本不匹配的报错也折腾了一晚上。所以这一篇环境准备，我决定把该踩的坑提前铺开讲清楚，给准备在 macOS 上编译 Chromium 的朋友一条相对顺的路。

先说清楚这东西能做什么：Chromium 是 Google Chrome 背后的开源项目，自己编译一份 144 分支的源码，意味着你可以定制功能、去掉不需要的模块、打自己的 patch、在本地带着符号表调试，也能顺手研究一下这个千万行级别的 C++ 项目是怎么组织和构建的。适合谁看？想深入浏览器内核的客户端开发者、想定制自己的浏览器的独立开发者，以及任何对大型开源项目构建流程感兴趣的人。

这篇是第一篇，聚焦在环境准备。后面我计划接着写源码同步、GN 参数调优、编译执行和产物打包，一步一步往下推。

1. 动手之前先想清楚：为什么值得在 macOS 上折腾 Chromium 144

1.1 官方 Chrome 和自编译 Chromium 的差别

很多第一次接触的人会问：Chrome 不就能直接下载吗，为什么要自己编一份？这里面的差别其实挺大。Chromium 是开源浏览器骨架，Chrome 是在这个骨架上做了二次加工的商业产品，额外带上了 Google 品牌、自动更新组件、专有编解码器授权、Flash 时代的遗留模块（虽然已经移除得差不多了）以及一些 Google 服务集成。你拿到的 Chrome 二进制是别人编译好的，里面启用了什么特性、裁剪了什么模块，你只能通过 chrome://flags 这类入口去调整，改不了事实上的编译期行为。

自己编译 Chromium 就不一样了。你可以通过 GN 参数开启或关闭特定功能，比如 proprietary_codecs 决定是否引入 H.264/AAC 这类有专利授权的编解码器，enable_nacl 决定是否保留 Native Client 模块（现在默认趋势是关闭），enable_widevine 控制 CDM 组件。你要是想给 password manager 或者渲染管线打 patch，也必须走自编译这条路。

另外就是版本号的问题。Chromium 的版本节奏大概每 4 周一个大版本，144 这个编号在主线推进序列里已经属于比较新的分支，带着一大堆新 API 和渲染层面的改动。如果你要跟 Web 平台的特性落地进度保持同步、或者围绕某个新特性做开发，那就得跟这种新版本分支。

1.2 编译一套浏览器下来，你能得到什么

这个工程量对个人开发者来说不算小，但收获也实在。我自己编译完最大的感受是，过去对浏览器"输入 URL 到页面显示"的认知是黑盒式的，编译一次你就会被迫弄明白几个点：GN 和 Ninja 是怎么描述和调度这个上千目标的大工程的；third_party 下面几百个第三方库是如何通过 DEPS 文件被组织起来的；链接阶段为什么会那么消耗内存和磁盘；以及为什么一个浏览器的构建产物可以跑到几十 GB。

从实用角度看，如果你是做前端或者客户端的，本地有一份带源码和调试符号的 Chromium，排查浏览器行为相关的问题会直接很多。比如怀疑某个渲染行为是不是 bug，你可以直接定位到 blink 层的源码，打上断点看调用栈，比黑盒猜测强得多。如果你后续想往浏览器定制方向走，比如做一个以 Chromium 为内核的桌面应用、套壳浏览器、或者类似 Electron 但更底层的定制化方案，这套编译能力就是基本功。

1.3 这个 macOS 系列准备怎么组织

我打算把整个流程拆成几篇：环境准备（也就是本篇）、源码同步与版本管理、GN 参数详解、编译执行与增量构建、产物打包与真机部署。这样每一篇控制在可操作范围内，不至于一篇塞太多东西，读者也不用一次吸收太多信息。

这一篇的核心任务非常明确：把硬件/软件环境、工具链、目录规划、基础命令跑通，最后到你能够生成 out 目录、跑通 gn gen 为止。编译动作本身下一篇再展开。

2. 环境准备的整体设计与方案选型

2.1 硬件要求：磁盘、内存和 CPU 的真实底线

先说大多数人最关心的硬件配置。我自己踩过的最痛的坑就是磁盘。Chromium 的源码仓库用 git 管理，拉下完整历史的情况下 .git 目录就非常占空间，source code 本体在 10~20GB 量级，再加上 gclient sync 从 CIPD 拉下来的各类预编译工具链、测试数据、资源文件，首次同步完成后的 src 目录轻轻松松三四十 GB。这还只是源码。到了构建阶段，Debug 模式下 out 目录里生成的中间文件、符号文件、动态库，动辄七八十 GB，如果你把 symbol_level 开到 2 保留完整调试符号，一百多 GB 都挡不住。

所以我的建议是：给这个项目留出至少 200GB 的可用磁盘空间。最好是一个独立的 APFS 卷宗，或者至少单独一个目录，避免和其他工作文件混在一起。用 macOS 自带的分区工具单独建一个卷宗会有个额外好处：APFS 是动态分配空间的，不会因为预分配把其他空间卡死，配合 Time Machine 排除规则还能避免备份工具整天去读你几十 GB 的构建缓存。

内存方面，16GB 是底线，但说实话非常勉强。链接阶段 ld64 或者 lld 吃内存很厉害，尤其是生成 chrome 这个最终可执行文件