缓存需匹配高频、多环境、高并发构建特征，分本地/持久化/远程三层协同；key须稳定敏感，冷启动需预热与分片策略，命中率应≥85%并监控写入延迟。
构建缓存不是“开了就快”，而是要匹配大流量场景下的高频、多环境、高并发构建特征。关键在于让缓存真正复用起来，而不是反复失效或写入冲突。
缓存层级要分清楚：本地 + 持久化 + 远程协同
单靠 Webpack 5 的 cache.type: 'filesystem' 不够——它只解决单机重复构建，但大流量项目往往有 CI/CD 多节点并行、多分支同时构建、预发/灰度/生产多环境共存等情况。
- 本地缓存（如 babel-loader cacheDirectory）：适合开发机或单构建节点，加速 JS/TS 转译，但不跨机器
- 持久化缓存（Webpack cache.directory + buildDependencies）：把 node_modules 版本、配置文件哈希纳入缓存 key，避免因依赖微调导致全量失效
- 远程共享缓存（如 Turborepo Remote Cache 或自建 HTTP 缓存服务）：CI 流水线中，不同分支、不同 PR 的相同输入可直接复用产物，实测可使 70%+ 的 PR 构建耗时降至 2 秒内
缓存 key 必须稳定且敏感：别让无关变更触发失效
很多团队开启缓存后效果差，是因为缓存 key 包含了时间戳、随机 ID、机器名等不稳定字段。Webpack 默认会监听配置文件和 package.json，但容易漏掉：
- 自定义 loader/plugin 的内部状态（比如某个插件读取了 process.env.NODE_ENV，但没声明为 buildDependency）
- Git 分支名或 commit hash 被硬编码进构建产物名（应改用 contenthash 或 fullhash）
- 未锁定的 lockfile 变更（建议 CI 中固定使用 pnpm-lock.yaml 或 yarn.lock 的精确哈希校验）
推荐做法：在 webpack.config.js 中显式声明所有影响输出的依赖：
webpackConfig.cache.buildDependencies = { config: [__filename, './babel.config.js', './tsconfig.json'] };冷启动要可控：避免首次构建变成“缓存重建风暴”
大流量项目上线新分支或重置 CI 缓存后，第一次构建常因缓存为空而飙升到 5–10 分钟。这不是瓶颈，是策略问题。
- 提前预热：在低峰期运行一次空构建（--watch=false），生成基础模块缓存
- 分片缓存：对 node_modules 和 src 分开缓存策略——第三方依赖变化频率低，可长期保留；业务代码变化频繁，启用更细粒度的 module cacheGroups
- 跳过非关键阶段缓存：例如压缩（TerserPlugin）本身支持缓存，但若使用 --parallel 参数，反而可能因进程调度争抢降低收益，建议仅对 babel/esbuild 等 CPU 密集型环节启用缓存
监控缓存命中率：没有数据就等于没优化
别只看总耗时下降了多少。真实大流量场景下，要盯住两个核心指标：
- 缓存命中率（Cache Hit Rate）：Webpack 日志里 “cache: restored x modules from cache” 占总模块数的比例，目标应 ≥85%
- 缓存写入延迟：filesystem cache 写入是否阻塞主线程？可通过 cache.idleTimeout 和 cache.idleTimeoutAfterLargeChanges 调整，默认 60s 太长，建议设为 10–20s
可在 CI 脚本末尾加一行统计：
grep -o "restored [0-9]* modules" build.log | awk '{sum += $2} END {print "Cache hit:", sum/NR "%"}'
