Bazel仓库构建中途挂起呈“无动作”状态的原因及是否正常

这种构建中途突然停滞挂起、毫无动作的情况绝对不是正常现象——Bazel的构建流程本质是按依赖拓扑有序推进的，正常情况下要么持续输出日志、要么报错终止，不会毫无动静地卡住。结合你提到的仓库包含大量自定义代码，我整理了几个原则上最可能的诱因：

• 资源竞争或耗尽：如果系统的CPU、内存或磁盘IO被其他进程占满，Bazel的worker进程会因无法获取足够资源而卡住。比如你的自定义代码执行了大量内存密集型操作，或者同时在运行其他重型任务，都可能导致这种情况；机械硬盘的IO瓶颈也会让构建进程长时间等待磁盘响应，看起来像“无动作”。
• 自定义规则/代码的阻塞逻辑：这是复杂仓库中最常见的原因。比如自定义规则里包含了同步等待外部资源的逻辑（比如等待一个未启动的服务，或者发起了没有设置超时的网络请求），或者代码中出现了死锁（多个自定义动作互相等待对方的输出、或者锁资源未正确释放）；还有一种容易忽略的情况：自定义执行的脚本或工具意外进入了交互模式（比如等着用户输入确认），但Bazel是无头运行的，没人响应就会一直挂着。
• Bazel自身的异常：虽然概率较低，但某些版本的Bazel在处理超大型仓库、复杂依赖拓扑或特定规则组合时可能出现死锁；另外缓存损坏也可能导致构建过程中陷入无限循环——比如Bazel在读取或写入缓存时出现异常，无法继续推进流程。
• 依赖解析的无限等待：如果你的仓库依赖了外部仓库，而该仓库的地址不可达、或者网络/代理配置错误，Bazel在拉取依赖时可能会一直处于连接等待状态；此外，依赖之间的循环引用也可能让Bazel的依赖解析逻辑陷入无限循环，表现为构建停滞。

针对这种难以复现的情况，你可以尝试这些通用排查方向：

• 用bazel build --verbose_failures --sandbox_debug命令重新构建，通过更详细的日志定位到停滞前最后执行的动作或规则
• 实时监控系统资源使用情况（比如CPU、内存、磁盘IO），确认是否存在资源耗尽的问题
• 检查自定义规则和代码中的等待、锁逻辑，排查是否有未处理的阻塞场景
• 执行bazel clean --expunge清理全部缓存后重新构建，排除缓存损坏的影响

内容的提问来源于stack exchange，提问作者Mark Karpov