ccache能救因头文件改动导致的全量重编，因其缓存粒度是单次编译命令，基于源码内容、编译参数、编译器版本及所有头文件展开后的完整哈希，而非文件时间戳；只要某.cpp未包含被修改的头文件，其编译任务仍可命中缓存。
ccache 能直接让二次构建快 5–10 倍，但前提是它真能“认出”这是同一任务——不是靠文件时间戳，而是靠源码内容 + 编译参数 + 编译器版本 + 所有头文件的完整哈希。
为什么改一个头文件就全量重编，ccache 还能救？
Make/Ninja 的增量构建只看 .h 文件修改时间，一动就连锁触发几百个 .o；ccache 不吃这套。它在预处理后对整个翻译单元做哈希，哪怕你只给 common.h 加了一行注释，只要某个 .cpp 没 include 它，那个目标依然命中缓存。
关键点在于：ccache 的缓存粒度是「单次编译命令」，不是「单个源文件」。
- 它缓存的是
gcc -O2 -DDEBUG -Iinc main.cpp这整条命令对应的结果 - 只要下次命令参数、
main.cpp内容、所有#include展开后的内容、甚至gcc --version输出都一致，就直接返回缓存的.o - 所以 CMake 中用
set(CMAKE_CXX_COMPILER_LAUNCHER ccache)比手动写ccache g++更稳——避免漏掉某些隐式调用
PATH 伪装法 vs. LAUNCHER 配置，哪个更容易翻车？
把 ccache 软链接成 gcc 放到 /usr/local/bin 并确保它在 PATH 前面，看起来很干净，但实际容易踩三个坑：
-
ccache通过argv[0]判断该调用哪个真实编译器，但如果项目里硬编码了/usr/bin/gcc路径，它就绕过 ccache 了 - 某些交叉编译环境（比如 OpenHarmony）会显式指定
--sysroot或--target，而软链接方式无法自动透传这些参数给底层 gcc - CMake 的
find_program(GCC)可能拿到的是你伪造的gcc，导致后续检测编译器特性失败
更稳妥的做法是：在 CMakeLists.txt 里用 CMAKE_C_COMPILER_LAUNCHER，或在命令行中显式传参：cmake -DCMAKE_CXX_COMPILER_LAUNCHER=ccache ..
缓存命中率上不去？先检查这三件事
运行 ccache -s 后发现 cache hit rate 低于 60%，大概率不是 ccache 问题，而是构建本身在“破坏一致性”：
- 编译命令里混用了绝对路径和相对路径（比如
-I./include和-I/home/user/proj/include），ccache 视为不同任务 - 启用了
-frecord-gcc-switches或-g且调试信息含时间戳（新版 GCC 默认关了，但老项目可能开着） - 构建脚本里动态生成了带时间戳的宏定义，例如
-DBUILD_TIME="$(date)"，每次哈希都变
临时验证是否命中：改一行代码后执行 ccache -c 清空缓存，再编译一次，然后立刻再编译一次——第二次的 cache hit (direct) 数应该接近总编译数。
缓存目录放哪、多大才合适？
默认缓存位置是 $HOME/.ccache，但别让它留在机械硬盘或 NFS 上——哈希计算快，I/O 才是瓶颈。
- 优先指向 NVMe SSD 分区，例如
ccache --set-config cache_dir=/fast/ssd/ccache - 大小设为
ccache -M 5G是通用起点；大型项目建议-M 10G，但别超过可用空间的 70% - 启用压缩能省空间且不明显拖慢：
ccache --set-config compression=true+compression_level=3（Zstd 算法）
最常被忽略的一点：ccache 不会自动清理过期缓存，-M 是硬上限，一旦打满，它会按 LRU 淘汰旧条目——这意味着频繁切换分支时，刚切回来的常用目标可能已被踢出。
