1. 项目背景与核心痛点拆解前端工程化走到今天构建速度已经成了影响团队日常开发节奏的关键指标之一。一个中型后台管理系统动辄两三千个模块webpack4跑一次生产构建七八分钟甚至十几分钟都是家常便饭。开发环境热更新慢、生产构建排队等这些问题叠加起来一天下来真正写代码的时间被压缩得所剩无几。这个项目要解决的核心问题就一个在 webpack4 体系下把打包耗时从分钟级压到秒级或几十秒级手段是多进程并行处理耗时 loader 和多进程并行压缩。先说清楚这个项目的适用人群。如果你正在维护一个基于 webpack4 的中大型项目构建时间超过三分钟且短期内没有迁移到更高版本构建工具的计划那这套方案就是为你准备的。如果你是小项目模块数量几百个以内那多进程带来的进程启动开销可能反而拖慢速度需要谨慎评估。另外这套方案对机器配置有要求CPU 核心数越多收益越明显四核以下提升有限。为什么 webpack4 的构建会这么慢得从它的工作模型说起。webpack 的核心构建流程大致是从 entry 出发递归解析模块依赖对每个模块应用对应的 loader 做转换然后把转换后的模块交给 acorn 解析成 AST再做依赖收集最后进入 chunk 生成和优化阶段。这里面最耗时的两个环节一个是loader 转换尤其是 babel-loader 处理 ES6 语法、ts-loader 处理 TypeScript、以及各种 css 预处理 loader另一个是代码压缩webpack4 默认用 UglifyJsPlugin单进程压缩面对几 MB 的 bundle 时 CPU 单核跑满其他核心闲着。这两个环节的共同特点是任务之间相互独立天然适合并行化。模块 A 的 babel 转换和模块 B 的转换没有依赖关系chunk1 的压缩和 chunk2 的压缩也互不干扰。既然单进程只能用一个核那多开几个进程把 CPU 吃满理论上就能把耗时按核心数摊薄。这就是整个优化方案的理论基础也是我选择多进程路线的根本原因。不过这里有个容易被忽略的点进程不是越多越好。每个子进程都有启动成本、内存开销和进程间通信成本。如果任务粒度太细进程调度和通信的开销会吃掉并行带来的收益。所以实际配置时进程数一般设置为 CPU 核心数减一留一个核给主进程和系统调度这个经验值在多数场景下比较稳。2. 多进程方案选型与工具对比2.1 为什么是 thread-loader 而不是 happypackwebpack4 生态里做多进程加速主流有两个选择happypack和thread-loader。我两个都实际跑过最后选了 thread-loader原因有几个。happypack出现得早webpack2、webpack3 时代是主流方案它的思路是把 loader 的执行委托给一个进程池通过HappyPack.ThreadPool管理。但它的问题在于配置繁琐每个 loader 都要单独包一层 plugin 和 rule而且对 webpack4 的兼容性维护逐渐跟不上社区活跃度下降遇到 loader 版本升级容易出兼容问题。thread-loader是 webpack 官方团队维护的放在 loader 链的最前面把它后面的 loader 丢到 worker 池里执行。配置极简就是一行use: [thread-loader, babel-loader]而且和 webpack4 的适配是官方保证的。它的原理是把 loader 的执行上下文序列化后传给 worker 线程worker 执行完再把结果传回来。注意thread-loader 后面的 loader 不能调用 webpack 的 API也不能访问自定义 plugin 注入的选项因为它跑在独立的 worker 里拿不到主进程的上下文。像mini-css-extract-plugin的 loader 就不能放在 thread-loader 后面会报错。2.2 并行压缩为什么选 terser-webpack-pluginwebpack4 内置的压缩插件是uglifyjs-webpack-plugin它其实也支持parallel参数开启多进程。但我更推荐换成terser-webpack-plugin理由如下。第一uglifyjs-webpack-plugin对 ES6 语法的支持不完整遇到箭头函数、可选链、async/await 这些语法要么报错要么需要先降级而 terser 本身就是为 ES6 设计的压缩更彻底。第二terser 的parallel参数默认就是os.cpus().length - 1开箱即用。第三terser 压缩后的产物体积通常比 uglify 小 3% 到 8%这个差距在大型项目里就是几十 KB 的差别。配置上在optimization.minimizer里替换掉默认的即可。这里有个细节webpack4 的mode: production会自动注入 uglify你需要显式覆盖 minimizer 数组否则 terser 不会生效。2.3 方案整体架构整个优化方案分三层loader 层并行、压缩层并行、缓存层兜底。loader 层用 thread-loader 把 babel、ts 这些耗时转换丢给 worker 池压缩层用 terser 的 parallel 把 chunk 压缩分给多进程缓存层用cache-loader或hard-source-webpack-plugin把首次构建的结果缓存下来二次构建直接读缓存。三层叠加首次构建能提速 50% 到 70%二次构建能提速 80% 以上。方案作用环节配置复杂度webpack4 兼容性推荐度happypackloader高一般不推荐thread-loaderloader低好推荐uglify parallel压缩低好可用terser parallel压缩低好强烈推荐cache-loader缓存中好推荐3. thread-loader 多进程打包实操配置3.1 安装与基础接入先装依赖注意版本要和 webpack4 匹配。thread-loader 用 2.x 版本terser-webpack-plugin 用 4.x 版本这两个版本区间和 webpack4 配合最稳。npm install thread-loader2.1.3 terser-webpack-plugin4.2.3 cache-loader4.1.0 --save-dev基础接入就是在耗时 loader 前面加一层 thread-loader。以 babel-loader 为例// webpack.config.js module.exports { module: { rules: [ { test: /\.jsx?$/, exclude: /node_modules/, use: [ { loader: thread-loader, options: { workers: 4, workerParallelJobs: 50, poolTimeout: 2000 } }, babel-loader ] } ] } };这里三个参数值得展开说。workers是 worker 数量一般设成 CPU 核心数减一我机器是 8 核所以设 4 到 6 之间都行设 4 是保守值避免主进程被抢资源。workerParallelJobs是每个 worker 同时处理的任务数默认 20我调到 50 是因为 babel 转换单个文件很快提高并发能减少 worker 空闲。poolTimeout是 worker 空闲多久后销毁默认 500ms我调到 2000ms因为构建过程中 worker 会反复用到频繁销毁重建反而浪费。3.2 哪些 loader 该放进 thread-loader不是所有 loader 都适合丢进 worker。判断标准是这个 loader 是否 CPU 密集且无副作用。babel-loader、ts-loader、eslint-loader 这类纯文本转换的适合。style-loader、css-loader、file-loader 这类涉及文件读写或依赖 webpack 上下文的不适合。我实际配置时只把 babel-loader 和 ts-loader 放进了 thread-loader。css 相关的 loader 处理量相对小放进去收益不明显反而可能因为 worker 通信开销拖慢。eslint-loader 我单独处理因为它需要读取.eslintrc配置放 worker 里路径解析容易出问题。// 只对 babel 和 ts 开启多进程 const jsRule { test: /\.jsx?$/, exclude: /node_modules/, use: [thread-loader, babel-loader] }; const tsRule { test: /\.tsx?$/, exclude: /node_modules/, use: [thread-loader, ts-loader] };3.3 缓存层叠加thread-loader 解决的是单次构建的并行问题缓存解决的是重复构建的浪费问题。cache-loader放在 thread-loader 前面把 loader 结果缓存到磁盘二次构建直接读。{ test: /\.jsx?$/, exclude: /node_modules/, use: [ cache-loader, thread-loader, babel-loader ] }提示cache-loader 的缓存目录默认在node_modules/.cache/cache-loaderCI 环境里如果每次都是干净构建缓存不生效可以关掉。本地开发时缓存命中率很高二次构建能省掉大量 babel 转换时间。这里有个坑我踩过cache-loader 和 thread-loader 的顺序不能反。如果 thread-loader 在前cache-loader 在后缓存读取发生在 worker 里而 worker 的缓存写入是异步的容易出现缓存不完整的情况。正确顺序是 cache-loader 在最前先查缓存没命中再进 worker。4. 并行压缩配置与参数调优4.1 terser-webpack-plugin 接入在optimization里覆盖 minimizerconst TerserPlugin require(terser-webpack-plugin); module.exports { optimization: { minimize: true, minimizer: [ new TerserPlugin({ parallel: true, terserOptions: { compress: { drop_console: true, drop_debugger: true, pure_funcs: [console.log] }, format: { comments: false } }, extractComments: false }) ] } };parallel: true是关键它让 terser 自动根据 CPU 核心数开进程。drop_console去掉生产环境的 consolepure_funcs进一步标记 console.log 为无副作用可删除。extractComments: false是不把注释抽成单独文件避免多生成一个.LICENSE.txt。4.2 并行压缩的进程数控制terser 的parallel参数除了布尔值还能传数字指定进程数。默认是os.cpus().length - 1但如果你同时开了 thread-loader两个池子会抢 CPU。我的做法是thread-loader 和 terser 的进程数加起来不超过核心数。8 核机器thread-loader 给 4terser 给 3留 1 个给主进程。new TerserPlugin({ parallel: 3, // ... 其他配置 })实测下来这样分配比两个都设true让它们各自抢要稳构建时间波动更小。如果机器是 16 核可以 thread-loader 给 8terser 给 6效果更明显。4.3 压缩效果对比数据我在一个约 2800 个模块的项目上做了对比测试机器是 8 核 16G。数据如下配置方案首次构建二次构建产物体积默认单进程412s398s4.82MB仅 thread-loader236s228s4.82MB仅 terser parallel298s285s4.61MBthread-loader terser168s162s4.61MB三层全开含缓存172s41s4.61MB可以看到首次构建从 412s 降到 168s提速约 59%。二次构建因为缓存命中直接降到 41s提速 90%。产物体积因为 terser 的压缩优化还小了 200 多 KB。5. 常见问题与排查技巧实录5.1 thread-loader 报错 Cannot find module这个报错通常是因为 worker 里的模块解析路径和主进程不一致。thread-loader 的 worker 默认从项目根目录解析如果你的 loader 配置里有自定义resolveLoader或resolve.modulesworker 可能找不到。解决办法是在 thread-loader 的 options 里显式传resolve配置{ loader: thread-loader, options: { workers: 4, poolTimeout: 2000 } }如果还不行检查是不是 loader 本身依赖了 webpack 的this上下文。thread-loader 的 worker 里this是受限的像this.emitFile、this.addDependency这些 API 调不了。遇到这种 loader只能把它从 thread-loader 后面移出来。5.2 构建结果不稳定偶尔产物缺失这个问题我遇到过两次一次是 cache-loader 缓存写入不完整一次是 terser 并行压缩时进程间通信超时。前者通过升级 cache-loader 到 4.1.0 解决后者通过降低 terser 的 parallel 数值解决。排查思路是先关掉所有并行配置确认单进程构建产物正常然后逐个开启定位是哪个环节出的问题。如果开了 terser parallel 后产物偶尔缺失把 parallel 从true改成具体数字比如 2 或 3通常能稳定。注意并行压缩对内存要求较高每个 terser 进程会占用几百 MB 内存。如果机器内存不足 8G建议 parallel 设为 2 或直接关掉否则容易触发 OOM。5.3 多进程后构建反而变慢小项目开多进程构建时间不降反升这是最常见的误区。原因是进程启动和通信的开销超过了并行节省的时间。判断标准是模块数量低于 500 个或者单次构建低于 30 秒不建议开多进程。另外如果项目里node_modules的依赖没有排除babel-loader 去转换第三方库那 thread-loader 的 worker 会被大量无意义的任务占满。务必在 rule 里加exclude: /node_modules/。5.4 常见问题速查表问题现象可能原因解决方向worker 找不到模块路径解析不一致检查 resolve 配置产物偶尔缺失并行通信超时降低 parallel 数值构建变慢项目太小或进程过多减少 workers 或关闭内存溢出并行进程吃内存降低进程数或加内存loader 报 this 相关错误worker 上下文受限移出 thread-loader缓存不生效CI 环境无缓存目录检查缓存路径配置6. 实操心得与进阶优化方向6.1 进程数不是越多越好我一开始图省事thread-loader 的 workers 直接设成 8terser parallel 也设true结果构建时间比设 4 还慢。原因是 8 核全开主进程和系统调度被挤占进程切换开销剧增。后来改成 thread-loader 4、terser 3留一个核给主进程时间反而降了 20 多秒。这个经验值不一定通用但思路是永远给主进程留至少一个核。6.2 缓存策略要分环境本地开发和生产构建的缓存策略应该分开。本地开发用 cache-loader缓存目录放在node_modules/.cache二次构建飞快。生产构建在 CI 上跑每次都是干净环境缓存没意义反而多一次磁盘写入。我的做法是用环境变量控制const isProd process.env.NODE_ENV production; const useCache !isProd; const jsLoaders [ ...(useCache ? [cache-loader] : []), thread-loader, babel-loader ];6.3 后续可以扩展的方向这套方案在 webpack4 上已经比较成熟但还有几个方向可以继续挖。一是dll 预编译把 react、lodash 这些不常变的库提前打包成 dll业务代码构建时直接引用能再省一大块时间。二是持久化缓存webpack5 的 filesystem cache 是内置的webpack4 可以用hard-source-webpack-plugin模拟效果接近。三是构建分析用webpack-bundle-analyzer和speed-measure-webpack-plugin定位真正的耗时大头避免盲目优化。我个人的体会是构建优化这件事没有银弹得先测量再优化。很多人一上来就开多进程结果项目本身模块就不多优化了个寂寞。先用speed-measure-webpack-plugin跑一遍看看 babel 转换占多少、压缩占多少、resolve 占多少再决定把资源投到哪个环节。数据不会骗人拍脑袋优化往往事倍功半。