文章 · 工程化
Monorepo 里那些没人告诉你的缓存陷阱
Monorepo 上了缓存之后，构建看着快了，但偶尔会「快」到把没编过的产物当成编过的。这类问题最麻烦的地方在于：它不报错，只是安静地给你一份错的东西。
陷阱一：只按文件内容算 key
只哈希源码内容是不够的。环境变量、依赖版本、构建脚本本身，任何一项变了都会改变产物。这些没进 key，缓存就会命中一个已经不该复用的结果。
陷阱二：跨包依赖没进图
A 包依赖 B 包，改了 B 却没让 A 重编——这是最典型的一类。构建系统必须知道包与包之间的依赖图，而不是各包各算。
陷阱三：把缓存当权威
缓存只能是加速手段，不能是唯一真相。关键分支上定期跑一次无缓存的全量构建做对照，是发现缓存污染最省事的办法。
构建变快是好事，但快得没有依据时，先怀疑缓存，再怀疑自己。
评论27
登录后参与评论，你的发言会署上自己的名字。
小弟@xiaodi1·2026-10-23
测试
小弟@xiaodi1·2026-10-23
测试
123@1·2026-10-22
测试
周迟作者@zhouchi·2026-09-16
放在最前面：看到都会回，先谢过各位补充的经验。
孟凡@mengfan·2026-09-17
构建脚本重写那段看着很有共鸣，最花时间的果然还是新旧产物对照。
段然@duanran·2026-09-18
缓存只能加速、不能当真相，这句话值得贴在看板上。
于野@yuye·2026-09-19
我们踩过一次，缓存里的数据比库里旧了两个版本，排查了很久。
于野@yuye·2026-09-19
跨包依赖没进图这个坑我们也踩过，当时查了整整两天才定位到。
秦舟@qinzhou·2026-09-20
建议再加一条：定期跑一次无缓存的全量构建做对照。
邓可@dengke·2026-09-21
把流水线耗时先打出来这一步太重要了，不然优化全靠猜。
罗叙@luoxu·2026-09-22
同意，先有数据再谈优化，不然改了半天不知道有没有用。
罗叙@luoxu·2026-09-22
并行分片我们试过，收益确实明显，但要注意任务之间的隐式依赖。
白露@bailu·2026-09-23
同感，我们是先画了一遍依赖图才敢拆的。