Webpack 5 持久化缓存需显式配置 cache.type = 'filesystem'，并设置 cacheDirectory、buildDependencies、snapshot 内容哈希及 loader 独立缓存，才能稳定命中、避免误失效，二次构建提速可达60%–80%。
Webpack 5 的持久化缓存不是“开个开关就变快”，而是要让缓存真正稳定命中、不被意外清空。配置得当，中大型项目二次构建耗时可从几十秒降到几秒，提速常达 60%–80%。
启用文件系统级缓存
这是最核心一步。Webpack 默认不开启持久化缓存，必须显式设置 cache.type = 'filesystem'：
- 在
webpack.config.js中添加完整 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 缓存管单文件转换过程——两者叠加才覆盖完整链路：
-
babel-loader：加
cacheDirectory: true和cacheCompression: false（开发时读取更快） -
esbuild-loader / swc-loader：通常自带高效缓存，确认文档是否需额外开启（如
cache: true） - 避免在 loader options 中使用动态值（如
new Date().getTime()或函数返回路径），否则缓存键不稳定，导致缓存失效
配置内容哈希快照，避免时间戳误失效
默认情况下 Webpack 依赖文件修改时间（mtime）判断变更，但编辑器保存、git checkout、CI 拉取都可能更新时间戳却不改内容，造成缓存被错误丢弃：
立即学习“Java免费学习笔记（深入）”；
- 启用基于内容的哈希比对：
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 文件是否被跳过、总耗时是否显著下降
