圣狗子在 macOS 上从源码编译 Chromium 144，第一件事不是急着敲编译命令，而是把环境准备做扎实。Chromium 的编译流程和普通开源项目完全不一样：它下层是一整套 depot_tools 工具链，依赖超过 20 个外部仓库，整个项目下载量动辄几十 GB，构建产物又是几十 GB。稍微少配置一样东西，后边都可能卡上几小时。这篇“环境准备（一）”专门解决从零到能跑通 autoninja -C out/Default chrome 之前的全部环节，适合三种人：想定制或学习浏览器源码的开发者、需要做自动化测试或内核研究的同学，以及单纯想验证“我在 macOS 上能不能自己造一个浏览器”的折腾派。
我直接把这些年踩过的坑揉进步骤里。你照着做，大概率能一次通，不用像我当年那样对着报错日志翻半天。
1. 编译前的硬性账目：硬件、系统和网络
1.1 硬件门槛：内存、硬盘与 CPU 的真实预算
先说硬盘。很多人对这个项目的体积没有概念——它不是一个 XXL 的仓库，是一整个“仓库群”。源码本身在拉取完依赖之后通常要占 20GB 到 40GB，取决于你有没有带完整 Git 历史；编译产物又会在 out 目录里堆出几十 GB。我个人的建议是最少预留 150GB 空闲磁盘，如果打算同时保留 Debug 和 Release 两套构建目录，那就按 250GB 以上算。别小看这一步，我见过好几个朋友编译到一半发现磁盘见底，最后只能删掉重来。
内存是另一个隐藏瓶颈。编译时 ninja 会按照核数并行开任务，每个编译进程都要吃几百 MB 内存，最后的链接阶段 lld 更是吃内存大户。16GB 是底线，但如果你用的是 8 核以上的机器，16GB 很容易在链接时被系统杀掉进程。我自己的感受是 32GB 才算舒服，Apple Silicon 的统一内存架构在这方面优势很明显。
CPU 方面，Apple Silicon 的编译速度比同代 Intel Mac 快出好几倍。M1 芯片完整编译一次 Release 版 Chromium 大约 2 到 3 小时，M2/M3 会更快；老款 Intel Mac 可能要跑一整晚。如果你用的是 Intel 机型，后面我会讲怎么手动限制并行数，避免把机器跑死。
1.2 macOS 系统版本与 Xcode 的版本对应关系
Chromium 官方对系统版本和 Xcode 版本的匹配要求很严格。以 Chromium 144 这个时间节点来看，macOS 12 以下基本不要想了，建议直接用当前最新稳定版 macOS，比如 macOS 15 Sequoia。为什么这么强调版本？因为 Chromium 的构建脚本会调用系统 SDK 里的头文件和链接库，SDK 太旧，编译到某个底层模块时就会冒出一堆“symbol not found”或者“unknown argument”之类的报错。
Xcode 也一样，最好是当前最新的稳定大版本，也就是 Xcode 16.x 这一代。这里有个细节：Chromium 官方 CI 每天跑的都是新系统新工具链，你用落后两个大版本的工具链去编译，遇到问题基本只能自己扛，官方文档不会管你。
如果你机器上同时装了几个版本的 Xcode，可以用下面命令切换：
bash复制sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
xcode-select -p
第二条命令输出为 /Applications/Xcode.app/Contents/Developer 就说明切换成功。这个切换操作在跨系统升级后特别常用，Xcode 路径一旦乱掉，后面所有构建脚本都会找不到编译器。
1.3 网络与下载：这是一个“几十 GB 级”的拉取任务
Chromium 源码托管在多个 Git 仓库里，主仓库之外的第三方库都靠 DEPS 文件声明版本，然后由 gclient 逐个拉取。整个 fetch 加 sync 过程下载量通常在 20GB 以上，这还没算编译工具链的下载。所以网络环境比“快”更重要的是“稳定”。
我最推荐的姿势是插网线，或者找一个信号强的固定位置，避免下载到一半 Wi-Fi 切换导致连接重置。gclient sync 虽然支持断点续传，但有些 zip 包下载中断后会从头再来，反复几次心态真的会崩。另外，同时开一大堆下载任务抢带宽这种事千万别干——我见过有人一边下源码一边挂游戏更新器，结果几十个依赖仓库轮流超时。
如果你连接官方代码托管源确实