Webpack 开启多线程打包反而变慢了，是配置错了吗？

FSD-静静提问于 2026-03-01 18:02:20 阅读 5

工具

我用 Webpack 5 的 thread-loader 给 Babel 加了多线程，但打包时间没减少反而更久了，是不是哪里配错了？

我的配置大概是这样的：

{
  test: /.js$/,
  use: [
    'thread-loader',
    {
      loader: 'babel-loader',
      options: { presets: ['@babel/preset-env'] }
    }
  ]
}

项目不大，就几个 JS 文件，难道小项目不适合开多线程？

Plugin Webpack 打包优化

我来解答赞 1 收藏

反馈

1 条解答

司马世杰 Lv1

你这直觉挺准的，问题就出在项目规模上。

先检查一下 thread-loader 的工作原理。它每次启动都要创建 worker 进程，进程间通信有开销，还有序列化反序列化的成本。你项目就几个 JS 文件，babel 编译可能本来只要 200ms，结果启动 worker 和通信就花掉了 500ms，这账怎么算都亏。

thread-loader 是给大型项目准备的，文件几百个起步、或者有大量 ES6+ 代码需要转译的场景才划算。像你这种小项目，单线程跑 babel-loader 反而更快，因为没有额外的进程通信开销。

直接把 thread-loader 去掉就行：

{

  test: /.js$/,

  use: [

    {

      loader: 'babel-loader',

      options: { presets: ['@babel/preset-env'] }

    }

  ]

}

如果以后项目变大了，文件上百个，再考虑加回来。到时候可以配合 cache-loader 或者 Webpack 5 的 filesystem cache 一起用，效果会明显。

顺便说一句，thread-loader 还有个坑是它不能和某些 loader 的链式调用完美配合，比如你用了 babel-loader 的 cacheDirectory，worker 进程的通信开销会更大。所以小项目真的别折腾多线程了，杀鸡焉用牛刀。

2026-03-01 18:08