2026年远程 Mac 上 Bazel 外源拉取与远程缓存：WORKSPACE 解析、磁盘 IO 与 CI 并发决策矩阵

解析阶段往往在数秒到数分钟内打出大量小体积 HTTPS 请求（Bazel Central Registry、自定义 registry、发行版元数据），随后才是 tarball / Git 对象的突发下载。远程 Mac 作为 CI 节点时，瓶颈通常不是「单文件不够快」，而是RTT 叠加、代理并发连接上限、以及与编译并行时的磁盘队列：同一时刻既有 repository_cache 写入，又有动作输出与沙箱临时文件，APFS 上表现为latency 抖动而非单纯带宽用尽。

bzlmod 下 MODULE.bazel 与 registry 解析链更长；老仓库仍以 WORKSPACE 为主时，http_archive 的 checksum 与镜像切换也集中在解析期。把「解析」与「编译」拆成独立 CI Job或至少串行阶段，能显著降低「外源超时」被误判为 flaky 的概率。

--disk_cache 缓存动作输出，适合单节点重复构建；--remote_cache（HTTP(S)/gRPC）在多台 Runner之间复用命中，适合共享远程 Mac 池。--repository_cache 则专门承接外源制品下载，应与二者一起规划路径与清理策略，不要与系统临时目录混用。

可执行示例（按环境改写路径与令牌）：

弱网下优先限并发再加长超时，否则多 Job 同时重试会放大重试风暴。下列标志为常见可调项（具体名称以你安装的 Bazel 大版本为准，可用 bazel help build 检索确认）。

Shell 层可对 bazel fetch @//... 或 bazel build //... 外包2s / 4s / 8s三次指数退避；仅对 fetch 步骤重试，避免整流水线重复链接。

问：主仓库 git clone --depth 1 会影响 Bazel 外源吗？ 一般不会：外源落在 output_base/external 与 repository_cache。但若 Starlark 或规则在配置阶段调用 git 读取提交历史，浅克隆会失败——应改为固定 tag/commit 的 http_archive或完整子模块初始化。

问：多 Job 同机并行要注意什么？ 避免共用同一默认 output_user_root；repository_cache 可读共享、写入仍需考虑锁竞争，高峰可按 Job 分子目录再定期归并。监控inode、剩余空间、iostat，磁盘阈值策略见 构建池并发与磁盘 FAQ。

问：bazel --jobs 与 Git 拉取同时进行？ 错开峰值：先完成 clone/fetch submodule，再拉高 --jobs；否则 SSD 队列上与网络下载争抢，表现为随机超时。

节点离制品源与远程缓存入口越近，解析阶段的小请求越不容易被 RTT 拖垮；若合规要求数据留在境内，应把 remote_cache 与 registry 镜像一并放在可达区内，而不是只加速 Git。并行编译（bazel build --jobs=N）会占用 CPU 与磁盘带宽，与「冷配置外源下载」叠加时，建议矩阵上限制 max-parallel，并为「仅 fetch / 分析」Job 单独设较低 --jobs。自托管 Runner 的标签与并发规划可参考 GitHub Actions 自托管 Runner 远程 Mac 指南。