ccache + target_precompile_headers + Ninja 组合可将大型C++项目全量编译从20分钟压至6分钟内；target_precompile_headers确保依赖精准追踪，ccache需规避路径、时间戳和编译器版本污染，Ninja通过固化依赖和零shell开销提升并行效率。
直接上结论：对大型C++项目，ccache + target_precompile_headers + Ninja 三者组合，能在不改代码、不换硬件的前提下，把全量编译时间从20分钟压到6分钟以内——这是美团DQU服务在32核机器上实测的结果。
为什么预编译头（PCH）必须配 target_precompile_headers 而不是手写 -include
手动用 g++ -include stdafx.h 或 MSVC 的 /Yu 看似简单，但实际会破坏构建系统的依赖追踪。CMake 的 target_precompile_headers 不仅自动生成 .gch/.pch 文件，还会自动注入依赖关系，确保头文件变更时精准触发重编译。
- 错误做法：
add_compile_options(-include common.h)—— 所有目标都强制包含，无法按 target 隔离，且不参与依赖图更新 - 正确写法：
target_precompile_headers(mylib PRIVATE <iostream><vector> "utils/config.h")</vector></iostream>—— PRIVATE 表示只影响该 target 及其私有实现，PUBLIC/INTERFACE 则控制传播范围 - 注意点：PCH 中不能含宏定义或条件编译逻辑；若头文件本身不稳定（如含
#define DEBUG），PCH 会失效甚至引发 ODR 违规
ccache 命中率低？检查这三处硬伤
很多人装了 ccache 却发现第二次编译没变快，根本原因不是缓存没生效，而是编译命令每次都不一样，导致 key 不一致。
- 路径绝对化：CMake 默认生成带绝对路径的
-I/home/user/project/include，而不同开发者路径不同 → 在CMakeLists.txt中加set(CMAKE_USE_RELATIVE_PATHS ON) - 时间戳污染：某些构建脚本插入
-DVERSION="20261020"这类动态宏 → 改用configure_file()生成版本头，避免每次编译都变 - 编译器版本漂移：CI 中 GCC 12.3 和本地 GCC 12.4 混用 → 强制统一
CC="ccache gcc-12.3"并在 CI 镜像中固化工具链
用 Ninja 替代 Make 不只是换个命令
Ninja 的本质是“最小化构建规则解析开销”，它不运行 shell，不展开通配符，所有依赖都在生成阶段固化为 flat list。这对千级源文件的项目，配置阶段就能省掉 3–5 秒。
立即学习“C++免费学习笔记（深入）”；
- 生成命令必须带
-G"Ninja"：cmake -G"Ninja" -DCMAKE_BUILD_TYPE=Release ..，漏掉-G仍走 Makefile 流程 - 并行数别硬写
-j16：Ninja 默认用nproc，但若项目含 heavy-link 阶段（如 LTO），应限制链接线程：ninja -j8 linkopts="-Wl,--threads=4" - 别信“Ninja 编译更快”的错觉：它本身不加速单个
.cpp编译，真正提速来自更激进的并行调度和更低的 rule 解析延迟
最容易被忽略的其实是头文件粒度——哪怕用了 PCH 和 ccache，一个 utils.h 里塞了 20 个无关声明，只要它被修改，所有 include 它的 300 个源文件都会重编。真正的瓶颈往往不在工具链，而在头文件的物理耦合程度。
