Webpack 的 cache 机制，是提升二次打包速度最直接有效的手段。核心思路是把已编译的模块结果持久化保存，下次构建时跳过重复工作。

Webpack 的缓存机制，说白了就是把模块编译后的结果尽可能持久化保存下来。这样一来，二次构建的速度往往能明显提上去。

到了 Webpack 5，通常更推荐把 filesystem 缓存打开，同时配合 babel-loader 的磁盘缓存，以及 terser-webpack-plugin 的压缩缓存一起使用。

至于这些缓存有没有真正生效，则可以借助 --stats-cached 这类方式来验证。

只要配置得当，二次构建耗时可降低 60%–80%，中大型项目从几十秒缩至几秒很常见。

Webpack 5+：启用文件系统缓存

Webpack 5 内置了强大的 cache 配置，推荐使用 type: 'filesystem'（硬盘缓存）。

它比内存缓存更稳定，复用率也更高。

• 在 webpack.config.js 中添加如下配置：

• 首次构建会生成缓存目录（默认 node_modules/.cache/webpack），后续构建直接读取；
• 缓存会自动感知 package.json、babel.config.js 等依赖变化，无需手动清理；
• 搭配 resolve.alias 或 resolve.symlinks: false 可避免因软链接导致缓存失效。

babel-loader 单独开启缓存

即使 Webpack 缓存已启用，babel-loader 仍可叠加一层磁盘缓存。

这样可以进一步加速 JS 转译环节。

• 在 rules 中为 babel-loader 添加 cacheDirectory: true：

• 它会把每个文件的 Babel 编译结果存到本地临时目录（如 node_modules/.cache/babel）；
• 特别适合含大量 ES6+ 语法或 TypeScript 的项目，转译耗时通常占构建大头；
• 注意：不要和 cache-loader（Webpack 4 时代方案）混用，Webpack 5 中已不推荐。

terser-webpack-plugin 压缩阶段也缓存

生产环境压缩 JS 是耗时操作，terser-webpack-plugin 支持缓存。

这样可以避免每次重新压缩相同代码。

• 在 optimization.minimizer 中启用：

• 缓存路径默认为 node_modules/.cache/terser-webpack-plugin；
• 配合 parallel: true 可进一步提速，尤其适用于多核 CPU；
• 注意：仅在 mode: 'production' 下生效，开发模式无需开启压缩缓存。

验证缓存是否生效

光配对还不算完，得确认它真正在工作。

• 启动构建时加 --stats-cached 参数，终端会显示缓存命中详情；
• 观察构建日志里是否有 cached modules、using cache 类提示；
• 检查 node_modules/.cache 目录下是否有对应子文件夹生成；
• 用 speed-measure-webpack-plugin 对比开启前后的各阶段耗时，重点关注 babel-loader 和 TerserPlugin 时间下降幅度。

适用场景总结

• 开发环境：优先开启 Webpack 5 的 filesystem 缓存，以及 babel-loader 缓存；
• 生产环境：除了前两者，还可配合 terser-webpack-plugin 压缩缓存一起使用；
• 效果验证：通过 --stats-cached、日志信息和缓存目录变化进行确认。

《夸克》非常好用的免费AI浏览器

下载APP查看