sccache在C++项目中常无加速效果的根本原因是默认配置下大量编译命令被判定为不可缓存，如含绝对路径、时间戳宏或调试开关等；需统一构建环境、正确设置LAUNCHER、禁用干扰哈希的选项并标准化路径。
为什么 sccache 在 C++ 项目里经常“没加速”甚至变慢
根本原因不是它坏了，而是默认配置下它几乎不缓存任何东西——C++ 编译命令里只要带一个绝对路径、时间戳宏、或调试信息开关，sccache 就认为这是“不可缓存”的编译单元。
- 常见错误现象：
sccache --show-stats显示Cache hits: 0，但Cache misses: 1247，且Non-cacheable compilations高得离谱 - 关键原因：Clang/GCC 默认开启
-g（含-grecord-gcc-switches）、-fdebug-prefix-map=缺失、-frecord-gcc-switches或-Wp,-MD等隐式引入绝对路径 - 必须统一构建环境：确保所有机器的
CC/CXX指向sccache包装器，且构建系统（CMake/Make/Bazel）不绕过它直接调用clang++ - 示例验证：
sccache -s后立即跑一次 clean build，再看Non-cacheable compilations是否下降；若仍高，说明编译命令里有未识别的不可缓存因子
CMake 项目中正确启用 sccache 的三步硬要求
CMake 自身不感知缓存，它只负责生成编译命令，所以关键在“让生成的命令被 sccache 完全接管”，而不是简单设 CC=sccache gcc。
- 必须在
cmake配置阶段传入：-DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache（注意是LAUNCHER，不是重设CMAKE_C_COMPILER） - 禁用影响哈希的编译选项：在
CXX_FLAGS中显式清除或覆盖掉-grecord-gcc-switches、-frecord-gcc-switches；对 Clang 加-Xclang -fno-record-gcc-switches - 路径标准化必不可少：GCC/Clang 需加
-fdebug-prefix-map=$PWD=/src（Linux/macOS）或/Zi /Fd"vc.pdb"配合sccache23.0+ 对 PDB 的支持（Windows）
sccache 缓存命中失败的典型编译参数陷阱
哪怕只差一个空格或一个绝对路径，sccache 就会拒绝复用缓存。以下参数最常导致“明明改了一行却全量重编”：
-
-I/home/user/project/include→ 改成-I$PROJECT_ROOT/include并用-fdebug-prefix-map映射$PROJECT_ROOT=/src -
-D__DATE__="..."或-D__TIME__="..."→ 这类宏让每次编译哈希都不同，必须从构建脚本中移除 -
-Wp,-MD,build/foo.d→ 生成的依赖文件路径含绝对路径，触发 non-cacheable；应改用-MD -MF $OUT_DIR/foo.d并确保$OUT_DIR是相对路径或已映射 - Clang 的
-fcolor-diagnostics默认开启，它本身不影响缓存，但某些旧版sccache（-fno-color-diagnostics 保兼容
本地开发与 CI 共享缓存时的权限和路径坑
本地 sccache 默认用本地磁盘缓存，CI 里想复用就得切到 S3/GCS，但路径处理稍有不慎就全失效。
立即学习“C++免费学习笔记（深入）”；
- 环境变量优先级高于配置文件：
SCCACHE_BUCKET、SCCACHE_REGION、AWS_ACCESS_KEY_ID必须在sccache进程启动前导出，CI 脚本里别漏export - S3 缓存路径映射必须一致：本地开发如果用了
-fdebug-prefix-map=/home/alice/myproj=/src，CI 里也得用完全相同的映射，否则源码哈希不一致 - Windows 上路径分隔符陷阱：
sccache22.0+ 才真正支持\路径归一化；若用老版本，务必在 CMake 中强制用/分隔，并在fdebug-prefix-map里写成C:/project=/src - 缓存污染难察觉：某次编译用了未清理的
-O3 -march=native，缓存进去后，其他机器即使 CPU 不同也会拉取该对象——建议在 CI 中固定-march=x86-64等可移植 flag
sccache，而是编译命令里那些看不见的路径、宏、调试开关——它们不会报错，只会默默让缓存失效。 
