bazel 重编整个库的主因是增量判断失效：头文件未声明、宏定义未纳入copts哈希、glob()导致依赖不敏感；buck受header_namespace和exported_headers影响；工具链与生成文件变更易被缓存忽略。
为什么改一行 foo.cpp 后，Bazel 有时仍要重编整个库？
Bazel 的增量判断依赖精确的输入哈希，但常见陷阱会让它“看不见”真实依赖：头文件没声明在 srcs 或 hdrs 里、宏定义通过编译参数传入（如 -DDEBUG）却没写进 copts 的哈希计算、用 glob() 匹配头文件但新增头文件没触发 BUILD 文件变更。这些都会导致 Bazel 认为“输入没变”，跳过重新编译，或者相反——因哈希失效而误判为全量重建。
实操建议：
- 所有被
#include的头文件必须显式列在cc_library.hdrs或srcs中，禁用未声明的隐式包含 - 把构建时决定的宏（
-DVERSION=123）统一收口到copts，避免散落在build --copt命令行里 - 慎用
glob(["*.h"])；改用静态列表或配合exports_files()+filegroup显式管理 - 用
bazel query 'deps(//path:target)' --output=build检查实际依赖图，确认头文件是否在其中
Buck 的 header_namespace 和 exported_headers 怎么影响头文件增量？
Buck 对头文件路径敏感，header_namespace 决定了 #include "xxx" 查找根路径，而 exported_headers 控制哪些头能被下游看到。如果改了一个被 exported_headers 暴露的头，所有引用该 target 的模块都会被标记为 dirty；但如果只改了 headers（非 exported）里的内部头，只有本 target 重编。
实操建议：
- 把公共接口头放进
exported_headers，私有实现头只放headers，避免无谓传播 -
header_namespace = "mylib"后，必须用#include "mylib/detail.h"，否则 Buck 找不到且不报错，导致缓存误命中 - 用
buck audit dependencies //path:target看哪些头被真正导出，比读 BUILD 文件更可靠 - 避免在
exported_headers里用通配符，Buck 不会自动感知新增文件，需手动更新 BUILD
修改 CC_TOOLCHAIN 配置后，Bazel 为何不自动清缓存？
Bazel 默认只对 BUILD 文件、源码、cc_toolchain 规则本身做哈希，但像 tool_paths 指向的编译器二进制、feature 开关状态这些外部配置，不会自动纳入 action key。结果就是：你换了 clang 版本，Bazel 还用旧 object 文件，链接时报符号不匹配或 ABI 错误。
实操建议：
- 把 toolchain 配置固化为 Starlark 规则，用
config_setting+select()绑定不同编译器路径，确保其哈希参与计算 - 在
cc_toolchain_config中显式调用ctx.attr.compiler_executable，而非硬编码路径，让 Bazel 跟踪文件变动 - 临时调试可用
bazel build --discriminator=clang15 //...强制刷新 action cache - CI 中禁止复用本地
--disk_cache，toolchain 变更时必须清空 remote cache 对应 key 前缀
为什么 Buck 的 cache_mode = "content" 比 Bazel 的默认模式更容易漏增量？
Buck 默认用文件内容哈希（content hash）判断输入变化，但若源码中包含生成文件（如 genrule 输出的头）、或用了 $(location :gen_target) 这类动态路径，Buck 在第一次构建时可能还没生成目标，就先算了一次空哈希，后续生成文件出现后，哈希变了却没触发重编——因为依赖关系图已固定。
实操建议：
- 所有生成文件必须用
genrule显式声明输出，并在消费方用$(location :gen_target)引用，不能靠相对路径猜 - 禁用
cache_mode = "content"，改用"rulekey"（类似 Bazel），让 Buck 把 rule 定义也纳入哈希 - 对含时间戳/随机数的生成逻辑（如版本号注入），用
stamping = True并绑定stamp = True，避免哈希抖动 - 用
buck targets --json //... | jq '.[].buck.base_path'快速定位哪些 target 用了生成文件
最常被忽略的是工具链和生成文件这两层间接依赖——它们不写在源码里，却决定着编译动作是否该重跑。一旦缓存错位，问题往往出现在链接阶段或运行时，而不是编译报错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
