Bazel 构建图分析器

你要解决的问题

Bazel 的构建优化常常卡在第一步：你知道自己慢，但不知道慢在哪。一个看似无害的 cc_library 改动，可能顺着依赖链把整棵编译树拖进来；某个 genrule 每次构建都被触发，却没人记得为什么存在。人肉翻 BUILD 文件得到的只是静态印象，真正决定耗时的是 Action 之间的依赖结构、缓存命中情况和服务端调度开销——这些信息散落在 bazel query 输出、aquery 事件流和 BEP 日志里，手工拼起来很费劲。

这个技能做了什么

它把三份数据源叠在一起分析：

• BQL（Bazel Query Language）：组合 deps()、rdeps()、kind() 等查询，回答「谁依赖了 X」和「X 依赖了什么」这类正反向问题。
• Action Graph API（aquery）：展开为具体的 Action，看清每一步在做什么、依赖哪些输入文件。
• BEP（Build Event Protocol）：拿到真实构建的流式事件，包括每个 Action 的起止时间、缓存命中结果和失败信息。

典型路径是：先用 BQL 圈定可疑目标，再用 aquery 展开它的 Action 集合，最后对照 BEP 记录确认这些 Action 是否真的执行了、耗时占比如何，从而定位瓶颈而不是凭感觉猜。

适用边界

• 它只分析构建图本身，不修改 BUILD 或 WORKSPACE 文件，也不会自动生成优化补丁。
• BEP 事件流的详细程度取决于启动 Bazel 时传的参数，部分信息可能缺失。
• 远程缓存和远程执行（Remote Execution）场景下的瓶颈分析，受限于事件日志的可见范围。
• 超大仓库里 BQL 查询本身可能较慢，建议先限定到子包范围再展开。