webpack缓存优化需按场景选型：cache-loader适用于webpack 4及以下，须置于耗时loader前并配合include/exclude；hard-source-webpack-plugin提供模块级磁盘缓存，提速明显但首次构建略慢且不可与speed-measure-webpack-plugin共存；webpack 5推荐原生filesystem缓存，开箱即用、集成度高，需配置builddependencies和cache.version以保障稳定性。
直接用缓存插件确实能显著提速，但关键不是“装上就快”，而是选对方式、配对场景、避开冲突。
cache-loader：轻量级缓存，适合Webpack 4及以下
它把loader处理结果（比如babel-loader转译后的JS）缓存到内存或文件系统，下次遇到相同输入直接复用。配置简单，但需注意位置和范围：
- 必须放在耗时loader之前，比如
cache-loader要写在babel-loader前面，顺序错了就不起作用 - 只对匹配的模块生效，务必配合
include或exclude缩小作用域，例如只缓存src目录下的JS，跳过node_modules - Webpack 5已内置持久化缓存，
cache-loader在新项目中基本可弃用，老项目升级前可作为过渡方案
hard-source-webpack-plugin：模块级缓存，提速更明显
它把整个模块解析、依赖图、AST等中间产物持久化到磁盘，重启dev-server或二次构建时直接加载，实测后续构建可快60%左右。但要注意几点：
- 首次构建会慢10%-15%，因为要生成完整缓存，别因此误判效果
- 不能和
speed-measure-webpack-plugin共存，两者同时启用会导致构建失败 - 建议与Webpack 5原生
cache: { type: 'filesystem' }二选一，混用反而降低稳定性 - 缓存路径默认在
node_modules/.cache/hard-source，可手动清理该目录重置缓存
Webpack 5原生持久化缓存：推荐首选方案
不用额外装插件，开箱即用，且和HMR、增量编译深度集成：
- 启用只需一行：
cache: { type: 'filesystem' } - 务必设置
buildDependencies，否则改了webpack配置不会自动清缓存，容易出错 - 搭配
cache.version可在团队协作中避免缓存污染（比如加Git commit hash作版本标识） - 金融类等大型项目实测：二次构建从18秒压到3秒，热更新响应也更稳定
提速前先定位瓶颈，别盲目加缓存
缓存不是万能解药。如果某次构建慢是因为某个loader处理了不该处理的文件（比如babel-loader扫了整个node_modules），加缓存只会把错误结果更快地复用一遍。
- 用
speed-measure-webpack-plugin跑一次构建，看哪个loader或plugin耗时最长 - 检查
babel-loader是否启用了cacheDirectory: true，这是最易忽略又见效最快的优化点 - 确认
include是否精确指向src，exclude是否明确过滤node_modules和第三方库
