webpack 5 持久化缓存需显式配置 cache.type = 'filesystem'，并设置 cachedirectory、builddependencies、snapshot 内容哈希及 loader 独立缓存，才能稳定命中、避免误失效，二次构建提速可达60%–80%。

Webpack 5 的持久化缓存不是“开个开关就变快”，而是要让缓存真正稳定命中、不被意外清空。配置得当，中大型项目二次构建耗时可从几十秒降到几秒，提速常达 60%–80%。

启用文件系统级缓存

这是最核心一步。Webpack 默认不开启持久化缓存，必须显式设置 cache.type = 'filesystem'：

• 在 webpack.config.js 中添加完整 cache 配置，例如：

cache: {
  type: 'filesystem',
  cacheDirectory: path.resolve(__dirname, '.webpack/cache'),
  buildDependencies: {
    config: [__filename, './babel.config.js', './tsconfig.json']
  }
}

• cacheDirectory 建议自定义路径（如 .webpack/cache），方便定位、清理，也利于 CI/CD 环境复用
• buildDependencies 列出所有影响构建逻辑的配置文件，一旦它们变更，Webpack 会自动清空缓存，避免错用旧结果

为 loader 单独启用磁盘缓存

Webpack 缓存管模块粒度，loader 缓存管单文件转换过程——两者叠加才覆盖完整链路：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• babel-loader：加 cacheDirectory: true 和 cacheCompression: false（开发时读取更快）
• esbuild-loader / swc-loader：通常自带高效缓存，确认文档是否需额外开启（如 cache: true）
• 避免在 loader options 中使用动态值（如 new Date().getTime() 或函数返回路径），否则缓存键不稳定，导致缓存失效

配置内容哈希快照，避免时间戳误失效

默认情况下 Webpack 依赖文件修改时间（mtime）判断变更，但编辑器保存、git checkout、CI 拉取都可能更新时间戳却不改内容，造成缓存被错误丢弃：

• 启用基于内容的哈希比对：

snapshot: {
  resolve: { hash: true },
  module: { hash: true }
}

• 这样 Webpack 会根据文件真实内容生成哈希，而非 mtime，大幅提升缓存命中率，尤其对 node_modules 下的依赖效果明显

配套优化与验证要点

缓存不是一劳永逸，还需注意几个关键点：

• terser-webpack-plugin 生产环境压缩阶段也建议开启 cache: true 和 parallel: true
• 修改 Webpack 配置任意字段（如 mode、devtool、resolve.alias）、升级 loader/plugin、改动 buildDependencies 中的文件，都会触发缓存清空——这是预期行为
• 验证是否生效：首次构建后检查是否生成缓存目录；第二次构建看终端输出是否有 cached modules 提示，或观察 unchanged 文件是否被跳过、总耗时是否显著下降

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南