Webpack打包优化配置实战踩坑经验总结

webpack optimization配置：到底该选哪种压缩方案？

最近重构项目的时候，又碰到了webpack optimization配置的老问题。说实话，搞了这么多年前端，每次遇到这个问题还是会纠结一下——TerserPlugin、ESBuild、SWC这些压缩器到底选哪个？这次我专门花时间对比了一下，记录下踩坑经历。

先说结论吧：开发环境我用ESBuild，生产环境还是TerserPlugin。为什么这么选？后面细说。

三种主流压缩方案的实际对比

目前主流的JavaScript压缩方案主要有三个：TerserPlugin（webpack默认）、ESBuild、SWC。我分别测试了它们在不同类型项目中的表现。

TerserPlugin方案：

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          compress: {
            drop_console: true,
            drop_debugger: true,
            pure_funcs: ['console.log', 'console.info']
          },
          mangle: {
            reserved: ['$', 'jQuery', 'window', 'document']
          }
        },
        extractComments: false
      })
    ]
  }
};

这是webpack5的默认配置，稳定可靠，兼容性最好。但速度真的是个问题，特别是项目变大之后，打包时间能让人怀疑人生。不过胜在稳定，各种edge case都能处理得很好。

ESBuild方案：

const ESBuildMinifyPlugin = require('esbuild-loader').ESBuildMinifyPlugin;

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [
      new ESBuildMinifyPlugin({
        target: 'es2015',
        css: true,
        minify: true,
        minifyWhitespace: true,
        minifyIdentifiers: true,
        minifySyntax: true,
        treeShaking: true
      })
    ]
  }
};

速度是真的快，比Terser快3-5倍，但稳定性差一些。之前我就遇到过ESBuild压缩后导致某个库的polyfill失效的问题，查了半天才发现是压缩器的问题。

SWC方案：

const SWCMinifyWebpackPlugin = require('@swc/counterplugin');

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [
      new SWCMinifyWebpackPlugin({
        mangle: {
          top_level: true,
          keep_classnames: false,
          keep_fnames: false
        },
        compress: {
          dead_code: true,
          unused: true,
          drop_console: true,
          drop_debugger: true
        }
      })
    ]
  }
};

SWC这些年发展得不错，速度也很快，生态相对成熟一些。但在某些复杂的语法转换上还是不如Terser稳定。

谁更灵活？谁更省事？

从配置灵活性来说，TerserPlugin绝对是王者。各种compress选项、mangle配置都支持得很完善，特别是那个reserved配置，解决了很多第三方库的命名冲突问题。ESBuild虽然速度快，但配置项相对较少，有些高级优化需要额外插件支持。

SWC的配置相对平衡，基本够用，但对于特别复杂的需求可能还是不够灵活。我之前有个项目用了大量的装饰器模式，Terser的配置就能完美支持，ESBuild和SWC都需要额外处理。

从上手难度来看，ESBuild最简单，基本就是开箱即用。Terser虽然配置项多，但文档还算清晰。SWC的话，社区文档质量参差不齐，遇到问题查资料有时候还挺费劲。

真实性能对比数据

我在一个中等规模的React项目（约100个chunk）上测试了三种方案：

• TerserPlugin：构建时间126秒，压缩后体积4.2MB
• ESBuild：构建时间28秒，压缩后体积4.1MB
• SWC：构建时间35秒，压缩后体积4.0MB

从体积来看差别不大，主要是压缩算法的细微差异。但从时间来看，ESBuild的优势确实明显。不过这里我要提个醒：速度提升是有代价的，特别是在处理一些特殊的语法结构时。

我在测试中还发现了一个坑：ESBuild对某些老版本的polyfill处理有问题，压缩后会导致IE兼容性问题。所以如果你的项目还需要支持IE，一定要谨慎使用ESBuild。

我的选型逻辑

基于实际开发经验，我现在的选型策略是这样的：

开发环境用ESBuild，主要考虑速度。开发时频繁编译，速度快能显著提升体验。而且开发环境下即使有一些压缩相关的edge case，影响也不大。

生产环境用TerserPlugin，主要是稳妥起见。毕竟生产环境出问题影响面大，稳定性比速度更重要。特别是对于企业级项目，稳妥第一。

SWC我会在新项目中考虑，特别是纯现代浏览器的项目。对于老项目，我还是倾向于Terser，风险更小。

另外还有一个折中方案：可以用ESBuild做初步压缩，然后用Terser做最终优化。但这样构建时间会叠加，实际用得不多。

踩坑提醒：这三点一定注意

首先是兼容性问题。ESBuild在处理某些老语法时会出问题，特别是当你的项目依赖一些比较老的第三方库时。我之前就遇到过压缩后某个图表库完全不工作的情况。

第二是Source Map问题。不同压缩器生成的source map格式略有差异，如果项目对错误监控要求很高，这点需要注意。Terser在这方面是最稳定的。

第三是Tree Shaking配合。ESBuild自身的tree shaking能力很强，但跟webpack的tree shaking机制有时会有冲突，需要调整配置。SWC在这方面相对平滑一些。

最终建议

如果你追求极致的开发体验，ESBuild是不错的选择，但要注意验证生产环境的兼容性。如果你的项目比较稳定，或者对兼容性要求高，Terser仍然是首选。SWC适合新项目，生态在快速完善中。

以上是我对这几个压缩方案的对比总结，有不同看法欢迎评论区交流。毕竟前端工具链变化太快，今天的经验明天可能就不适用了，持续关注才是王道。