Cache-loader 加了反而变慢，是我配置错了吗？

Des.传志提问于 2026-03-01 18:35:18 阅读 979

优化

我最近在项目里加了 cache-loader 想提升构建速度，但发现第二次构建比没加还慢，有点懵。

我是在 babel-loader 前面加的，配置大概是这样：

module.exports = {
  module: {
    rules: [
      {
        test: /.js$/,
        use: ['cache-loader', 'babel-loader'],
        include: path.resolve(__dirname, 'src')
      }
    ]
  }
}

是不是哪里搞错了？还是说 cache-loader 其实不适合小项目？

我来解答赞 1 收藏

反馈

1 条解答

Top丶沐岩 Lv1

你这个问题其实挺典型的，配置没写错，但思路有点偏。

cache-loader 的工作原理是在 loader 处理前先读缓存，处理后写缓存。这个读写磁盘的过程本身就有开销。第一次构建肯定变慢，因为要写缓存文件到 node_modules/.cache 里。第二次理论上应该快，但你遇到的情况大概率是：你的项目太小了，babel-loader 处理 js 文件本身就很快，可能就几十毫秒，而 cache-loader 读写缓存的 I/O 开销比这个还大。

这不是你配置的问题，是投入产出比的问题。就像你为了省 1 毫秒的 API 调用，结果加了个缓存层花了 10 毫秒去读写 Redis，得不偿失。

给你两个建议。

第一个，直接用 babel-loader 自带的缓存功能，把 cache-loader 去掉，改成这样：

module.exports = {

  module: {

    rules: [

      {

        test: /.js$/,

        use: [

          {

            loader: 'babel-loader',

            options: {

              cacheDirectory: true

            }

          }

        ],

        include: path.resolve(__dirname, 'src')

      }

    ]

  }

}

babel-loader 内置的缓存比 cache-loader 更高效，因为它知道什么时候该缓存、什么时候该失效，少一层 loader 管道开销也小。

第二个，如果你用的是 webpack 5，直接开持久化缓存：

module.exports = {

  cache: {

    type: 'filesystem'

  }

}

这个是 webpack 原生支持的，效果比 cache-loader 好太多，整个构建流程都能缓存。

总结一下，cache-loader 更适合那种 loader 处理特别耗时的场景，比如你用了一些很重的自定义 loader。对于 babel-loader 这种标配工具，用它自己的 cacheDirectory 就够了。小项目别过度优化，构建时间 5 秒以内的话，折腾这些收益不大。

2026-03-01 19:08