部署包体积一周翻倍，我拿sha256对账揪出是CI缓存没清

先说结论：这周部署包从 210MB 涨到 470MB，不是代码膨胀，是 CI 缓存里攒了三个版本的 node_modules 残留。

怎么发现的

周一发版，运维说包传得慢。我第一反应是依赖又加多了，但翻了下 package.json 这周就改了两个版本号。不对劲。

对账流程（建议你们也这么干）

1. 把上周和这周的部署包都解出来，各自跑 sha256sum 生成清单；
2. diff 两份清单，看新增文件和消失文件；
3. 新增文件里有一堆 node_modules/.cache 下的东西，还有嵌套了三层的 node_modules；
4. 用 du -sh 逐层看，发现 .cache 目录占了 180MB。

根因

CI 的缓存策略是「命中就复用」，但我们改过构建脚本，缓存 key 没跟着变，旧缓存一直没失效。每次构建往里叠，体积就滚雪球了。

处理

• 缓存 key 加上 lockfile 的哈希，文件一变缓存自动失效；
• 打包前加了一步清理：find . -name ".cache" -type d -prune -exec rm -rf {} +；
• 在流水线里加个体积门禁，超过 300MB 直接 fail，别等发出去才发现。

结果

改完这周包回到 215MB，解压时间从 40 秒降到 9 秒（Win解压缩实测，SSD 上三台机子取平均）。上传带宽也省了。

一个补充

排查这类问题别光看总大小，一定要拆到目录级别看。我一开始差点以为是 sourcemap 没关，结果一查 sourcemap 才 2MB，纯属冤枉。

你们 CI 缓存一般用什么策略？有没有遇到过缓存 key 设计不当导致包体持续膨胀的？