十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
改完一个按钮，接下来等软件重新打包。等待的这几分钟，很容易把注意力打断：原本只想确认一处细节，顺手去处理别的事，再回来已经忘了刚才准备看什么。
做咫尺时，手机、Mac、手表和小组件都要检查，我也想把这段等待缩短。最近试了一轮编译缓存，结果很有意思：同一份代码再跑一次，确实快了很多；真正改了共用代码之后，收益却小得多。
缓存可以理解成把做过的中间工作存下来，下次条件相同就继续用。它能帮我少做重复工作，但“上次跑得很快”还不足以说明日常开发也会一样快。
我先把四种情况分开记#
这次记录里，比较的是同一组检查的合计用时，单位是秒：
| 情形 | 合计用时 | 这次数字说明什么 |
|---|---|---|
| 不启用缓存 | 406 | 这轮比较的起点 |
| 刚启用、缓存还是空的 | 413 | 第一轮还要把可复用结果存起来 |
| 同一份代码再跑一次 | 62 | 已做过的工作可以大量复用 |
| 修改共用代码后再跑 | 386 | 很多依赖这部分代码的目标仍要重编 |
如果只截取 406 和 62，我也能写一个很漂亮的提速标题。但平时做产品，更多时候是在改代码，不是在反复检查完全相同的内容。
这组数据还不是严格的通用基准：当时电脑上还有其他构建，工具和工作路径也有具体条件。它适合解释这一次为什么快、为什么没那么快，不适合替所有项目承诺一个加速比例。
命中了很多缓存，为什么还是慢#
假设一个 App 的聊天、账本和小组件都依赖同一个共用模块。修改只影响某个按钮时，需要重做的范围可能很小；修改共用的数据类型时，手机、手表和扩展都可能跟着重新编译。
缓存命中率数的是“复用了多少工作项”，等待时间却取决于“剩下的工作有多重”。九个很轻的步骤命中，最费时的那个步骤没命中，整体仍然会慢。
所以我现在看日志，会把命中率和耗时放在一起，再问：这次改了什么？最慢的是哪个目标？这部分为什么不能复用？否则很容易把一个好看的百分比当成已经解决了等待问题。
先在一处试，别把所有机器一起改#
缓存会占磁盘，也会依赖工具版本、编译选项和文件位置。目录变了，先前存下来的结果可能就用不上；工具升级之后，也可能需要重新积累。
我更愿意先在一条稳定的检查路径上试：固定比较对象，记录冷启动、同代码重跑和真实修改，观察几轮磁盘增长，再决定是否推广。检查仍然要报告警告和错误，不能为了快就把质量检查关掉。
这也给回退留了空间。发现收益有限，可以关掉这项试点；清理时只处理本项目明确拥有的缓存，不靠扫掉整台电脑的目录来换一次漂亮成绩。
下一次怎样判断值不值得继续#
我会留一张小表：源码改动类型、工具版本、是否有其他任务、缓存命中情况、各阶段耗时和磁盘占用。至少连续观察几次真实开发，再看等待是否变少。
如果主要损失来自排队，应该处理任务分工；如果来自重复检查，应该看触发范围；如果来自公共模块牵动太多目标，再讨论模块边界。缓存只是其中一项。
这轮最有用的收获，是我知道哪些重跑适合缓存，哪些等待仍然需要另找原因。少等几分钟有价值，但目前没有把它换算成电费、云费用或收入，也没有把一次试验写成整套设备都已经推广完成。