webpack 5原生cache是当前最优解，覆盖全流程且开箱即用；cache-loader仅缓存单个loader输出，webpack 5中babel-loader自带缓存更轻量；hard-source-webpack-plugin已弃用，不兼容webpack 5。
在 Webpack 性能优化中，cache-loader 和 hard-source-webpack-plugin 都是为了解决大项目二次构建慢的问题，但它们作用层级、原理和适用场景不同。实际工程中建议优先使用 Webpack 5+ 原生 cache，再按需补充或迁移旧方案。
cache-loader：针对单个 loader 的执行结果缓存
它是一个 loader，必须显式插入到耗时 loader（如 babel-loader、ts-loader）之前，只缓存该 loader 的输出结果。
- 安装：
npm install cache-loader -D - 配置示例（放在 babel-loader 前）：
module: { rules: [{ test: /\.js$/, use: ['cache-loader', 'babel-loader'], include: path.resolve(__dirname, 'src') }] } - 缓存默认存于
node_modules/.cache/cache-loader，支持自定义路径（通过cacheDirectory选项） - 注意：Webpack 5+ 中，babel-loader 自带
cacheDirectory选项，效果与 cache-loader 接近，且更轻量，推荐优先启用：use: ['babel-loader?cacheDirectory=true']
hard-source-webpack-plugin：模块级全量缓存（已基本弃用）
它在 Webpack 4 时代较流行，通过独立缓存模块解析、AST 转换、依赖图等中间产物，大幅加速二次构建。但不兼容 Webpack 5，官方已停止维护，社区无稳定升级版。
- Webpack 4 项目若仍在用，配置方式为：
const HardSourceWebpackPlugin = require('hard-source-webpack-plugin'); module.exports = { plugins: [new HardSourceWebpackPlugin()] }; - 缺点明显：缓存体积大、偶尔失效导致构建错误、与 HMR 冲突、不支持持久化跨机器共享
- 2026 年起，新项目不应引入；存量 Webpack 4 项目建议逐步迁移到 Webpack 5 原生缓存
Webpack 5 原生 cache：推荐的现代替代方案
Webpack 5 内置了强大、稳定、开箱即用的持久化文件系统缓存，覆盖模块解析、loader 执行、chunk 生成等全流程，是当前最优解。
- 最小化配置即可启用：
cache: { type: 'filesystem', buildDependencies: { config: [__filename] } } - 首次构建略慢（因写缓存），后续启动快 50%–80%，尤其对含数百个模块的中大型项目效果显著
- 自动处理 loader 缓存（只要 loader 支持
this.cacheable()，babel-loader/ts-loader 均支持） - 支持缓存清理（
webpack --clean-cache）和目录自定义（cacheDirectory）
验证与调优建议
不要凭感觉优化，用数据说话：
- 装
speed-measure-webpack-plugin，对比开启 cache 前后的各阶段耗时 - 观察
node_modules/.cache/webpack目录增长是否合理（通常 100–500MB） - 开发环境务必开启 cache；CI 环境若使用干净容器，可配合
cache: { type: 'memory' }或跳过缓存 - 避免同时启用 cache-loader + Webpack 5 cache，会造成冗余，反而拖慢
