做 C 开发的时间长了一定会被构建时间折腾过。改一个头文件几十个源文件跟着重新编译在本地机器上就是几分钟放到持续集成环境里可能直接变成半小时起步。我前阵子梳理一个老项目双人开发全新构建一次接近二十分钟每天要跑好几轮流水线光等编译就占掉一大块时间。后来系统性地把“C构建缓存加速”这件事在本地和 CI 两边都做了一遍构建时长从二十分钟压到四五分钟命中率稳定在 80% 以上。这篇文章没有绕弯子的理论只有我在实际接入过程中用过、踩过、验证过的方案从缓存原理讲起接着是 ccache 和 sccache 的选型再到本地和 CI 的具体配置最后把常见坑和排查思路一次性列出来。无论你是刚接触编译优化还是给一个老工程做减负都可以照着试。1. C 构建为什么慢从编译流程看缓存的机会点1.1 一次编译的时间究竟花在哪里C 的构建通常分为预处理、编译、汇编、链接四个阶段。预处理阶段要把#include引入的所有头文件展开代码里每个宏定义和条件编译指令也要在这里处理。一个稍微成规模的工程单个源文件动辄包含几百个系统头文件和项目头文件预处理阶段需要反复读盘、展开、生成中间表示这部分开销是很多人最先感受到的“慢”。编译阶段更明显。编译器要把展开后的源码解析成抽象语法树做语义分析再做模板实例化和各种优化。模板元编程在编译期展开意味着短时间内编译器可能生成大量机器代码。链接阶段则要把所有目标文件合并、处理符号和重定位一个大型项目在最后链接时也常常要等上一两分钟。我接手过的那个项目体量在十万行上下全新构建时预处理和编译占掉 70% 以上的时间。这个比例非常典型代码越多、头文件嵌套越深编译阶段越容易成为瓶颈。理解了这一点自然能想到一个方向——同一个源文件在输入条件没变的情况下为什么要每次重新编译一遍1.2 缓存加速的本质按内容寻址的复用构建缓存的核心思路是把一次编译的结果保存下来下一次构建时如果发现输入没变就直接复用之前生成好的目标文件跳过预处理和编译这两个最耗时的阶段。关键在于“输入没变”这件事怎么判断。业界通用的做法是内容寻址拿源文件内容、涉及的每一个头文件内容、编译器版本、编译参数、当前平台等等信息一起计算一个哈希值把这个哈希值作为缓存的键。之后构建时重新计算哈希如果命中就把之前缓存的.o文件或者.obj文件拿回来用。你可以把它想成食堂出餐同一道菜食材一样、做法一样、掌勺师傅没换那成品就可以直接端走如果换了配菜或者换了调味方式那必须重新炒。C 构建缓存也是这个逻辑缓存的是编译产物而不是人的记忆。这里有个容易被忽视的前提缓存必须关心“编译参数”。同样是foo.cppDebug 和 Release 的优化级别不同产物不能互用头文件搜索路径不同宏定义不同编译器版本不同这些都会导致结果不一致。所以工具在计算哈希时会把命令行参数完整记录下来凡是有可能影响产物的信息都不能漏。1.3 增量编译与缓存加速的边界有人会问构建系统本身不是已经有增量编译了吗改了代码之后只会重新编译受影响的文件为什么还需要额外的缓存增量编译是靠文件时间戳和文件内容的变化判断哪些源文件需要重新编译它能避免“全量重编每一次”但有一个天然缺口如果某个公共头文件被改动所有包含它的源文件都会被标记为过期整个工程需要重编这些文件。可是很多源文件实际上可能只是包含了这个头文件的一两个声明业务逻辑根本没变。增量编译没有能力判断这点只能把相关的文件都重编一遍。构建缓存则更细粒度。它不关心源文件是否引入了某个头文件只关心源文件包含的内容经过展开后最终实际参与编译的内容有没有变化。头文件改动没有影响到某个.cpp的扩展结果对应目标文件的哈希就完全一致缓存直接命中这个文件根本不需要重编。增量编译和缓存加速两者不冲突而是叠加关系。构建系统负责确定哪些文件需要重新处理缓存工具负责在这些文件的编译过程中躲掉重复计算。把增量当作第一道筛子把缓存当作第二道筛子这才是完整的加速策略。2. 工具选型ccache、sccache 怎么选2.1 ccache本地加速的首选ccache 是 C 构建缓存工具里最成熟也最普及的一个。它通过拦截编译器调用计算输入信息和编译参数的哈希命中缓存时直接返回缓存的目标文件未命中时才真正调用底层编译器并把结果放回缓存。接入方式非常简单不需要改编译器不需要改构建脚本逻辑。最原始的办法是在编译命令前面加ccache前缀例如ccache g -c foo.cpp。但更规范的做法是在构建系统里把CMAKE_CXX_COMPILER_LAUNCHER设置为ccache这样所有编译命令都会自动包裹。ccache 的优点是对 GCC 和 Clang 的工具链支持非常好命令行参数的哈希计算很细致版本迭代也快。本地开发场景下一两个开发者共用一个缓存目录效果立竿见影。它的主要限制有两个一是默认缓存存储在本地磁盘跨机器共享需要额外配置网络文件系统或手工拷贝二是它主要作用于编译阶段对链接阶段基本没有加速作用。如果你的目标环境是个人开发机或者小团队共享一台构建机ccache 几乎是最佳选择零成本、高收益。2.2 sccache更适合分布式场景的开源方案sccache 是另一个常用的 C 构建缓存工具思路和 ccache 相似但重点是解决缓存共享和分布式场景需求。它可以配置本地磁盘、内存、后端对象存储等多种存储方式。与 ccache 相比sccache 的一个明显优势是跨机器共享缓存非常方便。多台 CI 构建机器可以连接同一个后端存储A 机器编译生成的目标文件B 机器可以直接命中。对于持续集成环境、多分支并行构建、频繁拉分支跑测试的团队来说这个能力能把重复编译时间大幅度压缩。sccache 同样支持 C/C也支持 Rust 生态如果你团队里有多种语言的构建需求可以统一接入。我用 sccache 替代原来 CI 里的 ccache 之后体会到的差别主要在缓存管理上。sccache 的后端存储天然支持多个客户端读写并发控制做得好不会像手工共享网络目录那样容易出现缓存文件互相覆盖的问题。代价是部署复杂度高了一些需要额外运维一个存储服务。选型时可以简单归类单机或小团队场景选 ccacheCI 多实例并行场景选 sccache。两者不是对立关系本地开发仍然用 ccacheCI 用 sccache也很常见。2.3 缓存工具不是银弹PCH、模块与合并编译缓存加速解决的是重复编译问题但有些极度耗时的编译工作即使缓存命中也没法完全规避。比如模板库的深度实例化、头文件本身的展开这部分在第一次完整构建时依然要花时间。为了进一步压缩首次构建和冷缓存场景的耗时业界还有几个常见手段。预编译头文件PCH可以把常用的系统头文件提前编译成二进制状态之后每个源文件包含这些头文件时不再逐字解析而是直接加载编译好的结果。C20 的模块Module也是类似目标从语言层面改善头文件展开的性能。合并编译Unity Build则是把多个.cpp合并成一个编译单元减少预处理和编译启动的重复开销。这些手段和缓存工具并不冲突。第一次构建时PCH 和模块能降低底层的绝对工作量缓存工具负责在后续构建中不让同样的事重复发生。实操中我建议先把缓存接入跑通再考虑要不要引入 PCH 或者模块因为后者对代码组织方式有侵入调试配置也复杂不是所有项目都适合。3. 实操记录本地接入缓存与命中率调优3.1 接入 ccache 的最短路径我以常见系统下的操作举例。先把 ccache 装上命令很简单# 常见的包管理器安装方式按你自己系统选择 sudo apt install ccache brew install ccache安装完成后验证版本号ccache --version然后就是接入构建系统。如果你用的是 CMake最推荐的方式是在配置工程时指定启动器cmake -S . -B build -DCMAKE_CXX_COMPILER_LAUNCHERccache这样配置之后CMake 生成的编译规则里每次调用编译器都会自动带上 ccache不需要改动任何源码文件。我再提醒一下CMAKE_CXX_COMPILER_LAUNCHER可能在你后来重新配置工程的时候被覆盖所以最好把它写进 CMakePresets.json 或者脚本里保证每次配置都用同一个参数。如果不想用 CMake而是手写 Makefile那也可以直接修改编译命令CXX ccache g还有一种做法是把编译器路径直接替换成 ccache 的软链让系统以为 ccache 就是编译器。这种方式侵入性稍强但对不支持启动器参数的构建脚本挺有效我不太推荐新手一上来就用排查问题的时候容易搞混。3.2 缓存目录和命中率统计ccache 跑过一次构建之后可以用ccache -s查看统计信息。这里你能看到命中次数、未命中次数、缓存大小、被清理的文件数量等数据。我在本地项目里最常用的检查命令是ccache -s ccache -d-s是 summary 统计-d是显示缓存目录所在位置。缓存默认在用户目录下的.ccache文件夹如果磁盘空间紧张可以用ccache -M 5G把缓存上限设为 5GB。这个上限不是“到了就停止运行”而是指缓存会在后台自动清理老条目把空间控制在目标值附近。刚接入时命中率可能只有 30% 到 50%这不奇怪。第一次完整编译把所有产物写入缓存第二次构建才能看出效果。你可以在同一份代码上跑两次完整构建第二次的编译时间应该明显下降。真正要关注的是长期命中率。我在本地做过统计一个模板用得多的项目稳定运行两周后命中率能到 85% 上下一个频繁修改公共头文件的项目会低一些这跟代码改动习惯强相关。3.3 命中率优化学会审视编译参数缓存命中率的杀手往往不是代码改动而是编译参数里藏了不稳定因子。最常见的两个元凶是__DATE__和__TIME__。代码里只要有这些宏参与拼接版本号或者构建信息那么每次编译的命令行哈希虽然一样但展开后的源码内容其实变了会导致对应的目标文件必须重新编译。如果你希望保留构建时间戳信息可以牺牲一点点“绝对的缓存命中率”把日期时间相关的宏放在一个单独的源文件里而不是放进公共头文件。这样其他文件不会因为日期变化而失效只有那个专门记录编译时间的文件会重新生成。另一个影响命中率的因素是绝对路径。如果你的构建系统在编译参数里传了绝对路径比如-I/home/user/project/include那么工程挪到别的位置后所有缓存都会失效。虽然在本地不挪项目路径的情况下没感觉但在 CI 环境里不同构建目录很容易造成每次路径都变。我的建议是优先保证参数稳定路径统一使用相对根目录的结构编译器版本也尽量锁定。ccache 的哈希计算里本来就会包含编译器版本信息工具链升级会合理触发全量缓存失效这属于正常现象不是 bug。4. 在 CI 流水线中启用共享缓存4.1 用 sccache 做跨机器缓存共享本地缓存只能解决一台机器上的重复构建CI 场景更疼的问题是每次跑流水线都可能在一个新环境里之前编译的东西全部丢失。不同分支并行跑流水线时大家都在重复编译同一批基础代码。我在 CI 中采用的方案是 sccache 配合后端对象存储。大致流程是在构建容器里配置环境变量把SCCACHE_BUCKET和对应的访问凭据指向一个共享存储桶然后让 CMake 使用sccache作为编译器启动器。这样所有构建机读写同一个缓存后端产物可以共享。SCCACHE的配置里有一个参数SCCACHE_IDLE_TIMEOUT控制本地临时缓存保留时间还有SCCACHE_CACHE_SIZE控制缓存大小。我最初没理解这些参数直接把默认配置丢上去后来发现部分节点命中率很低。排查之后确认是缓存后端连接不稳定临时缓存一过期等于每次冷启动。有个经验值得单独说别把 CI 的缓存无限放大。缓存太大之后构建机从后端拉取缓存数据的时间可能比重新编译还要长。我遇到过一个极端情况缓存后端里的对象文件有几十 GB客户端每次启动要花几分钟同步元数据整体收益被拖没了。合理的做法是定期清理不活跃的缓存条目或者按照分支和项目分别使用不同的缓存前缀。4.2 多构建矩阵的缓存策略如果你的 CI 有多个构建矩阵比如 Debug、Release或者不同编译器版本缓存策略要特别小心。最简单的原则是不同编译配置使用不同的缓存键前缀不要混在一个桶里。我在一个模拟项目 X 上做过这样的配置在 sccache 的缓存键里加上构建类型和编译器名比如cache/debug-gcc、cache/release-gcc、cache/release-clang。这样可以确保它们不互相污染。否则 Debug 和 Release 的目标文件格式差距很大一旦某个构建误读了另一个配置的产物轻则缓存不命中重则直接链接失败。还有一个和 CI 强相关的场景干净环境测试。团队偶尔需要在新拉取的镜像里做一次全量构建验证项目依赖是否完整。这种时候如果共享缓存打开构建可能会不断命中缓存掩盖了环境初始化的问题。所以我会额外保留一条不启用缓存的流水线任务做健康检查这两条流水线用不同配置名区分。缓存就像工具不要让它替你做决定要主动设计它怎么参与。5. 常见问题与排查技巧实录5.1 缓存命中率为零到底哪里出了问题我见过不少接入构建缓存后命中率直接为 0 的情况。排查看似复杂其实按顺序查几个点就能定位。先确认编译器启动器有没有真的生效。CMake 配置了CMAKE_CXX_COMPILER_LAUNCHER之后可以查看生成的compile_commands.json看里面的编译命令是否真的有 ccache 或 sccache 前缀。有时候缓存启动器没有写入最终构建规则徒有配置自然没有效果。再确认缓存目录是否可用。用ccache -s查看如果统计信息里的files in cache一直是 0可能是权限或磁盘空间问题。还有一点本地文件系统不支持某些文件锁时ccache 会处于保守模式宁可全部重编也不拿缓存。还要看编译参数里的路径相关项。目录名每次变化哈希自然变命中率就上不去。CI 环境经常出现这个问题构建根目录带时间戳或者任务编号几分钟到几十分钟就切一次缓存永远追不上变化。最后检查编译器版本。GCC 或 Clang 的小版本升级也可能导致缓存失效这是工具故意设计的为了安全宁可不命中也不能错误复用老产物。5.2 缓存膨胀、工具链切换和清理策略缓存用久了必然膨胀。ccache 提供了几个常用控制命令我习惯定期执行ccache -C # 清空全部缓存 ccache -M 5G # 设置缓存上限 ccache -F 100000 # 设置最大文件数如果项目从 GCC 切到 Clang或者升级编译工具链版本建议不要直接沿用旧缓存目录。虽然工具正常会因编译器版本不同重新计算哈希但为了避免某些极端情况下目录污染手动清一次更保险。我自己的习惯是切换工具链后执行一次ccache -C然后跑一次全量构建重新预热。清理策略要和团队共享。如果大家都用同一个缓存目录有人随手清了缓存其他人的首轮构建就会变慢。更好的做法是让缓存目录的清理规则自动化依靠缓存大小上限触发清理而不是人为干预。5.3 用量化数据验收加速效果接入缓存后怎么判断效果到底好不好我建议记录三个指标完成一次全新构建的时间、完成一次带缓存构建的时间、缓存命中率。分别对应冷缓存场景、热缓存场景和缓存健康度。我在一个模拟项目 X 上实测源码规模约十万行GCC 编译器CMake 构建。冷缓存全新构建耗时 18 分钟热缓存第二次构建只要 4 分钟命中率 87%。这个结果放在真实项目里可能更夸张尤其是模板多、头文件嵌套深的项目热构建时间能压缩到冷构建的五分之一。如果你发现热构建时间没有明显下降那就该看看是不是大文件过度频繁被修改或者掉了某些不稳定参数。构建时间这个指标受代码量影响大但命中率这个指标是相对稳定的你看长期趋势就行。还有一个小技巧把 ccache 的统计输出接进 CI 日志。在流水线脚本末尾执行ccache -s | tee -a build_stats.log这样每次构建都会留痕等周报或者复盘时直接翻日志就能看到缓存表现变化的曲线不用临时手工去翻历史环境。我自己在这套方案上踩过最大的坑是以为缓存配置好之后就能一劳永逸。实际上 C 构建缓存加速是一个需要持续观察的工程代码结构会变、编译参数会变、构建机器会变缓存命中率和构建时间都在动态起伏。定期检查统计信息、保持缓存目录总量可控、在 CI 日志里留痕才是长期稳定的关键。如果你正准备接入不用一开始追求完美的共享方案先把本地 ccache 跑起来感受一下热构建和冷构建的差别再根据团队需要决定要不要上分布式缓存。
