编译优化那些事儿：从理论到实践的性能提升之路

编译优化：我踩过的那些方案对比

最近重构了一个大型项目，涉及到编译优化这块儿，踩了不少坑。之前一直觉得打包工具就是webpack一把梭，直到这次项目规模上来后才发现，不同的编译优化方案差别还是挺大的。今天就把几种主流方案拉出来遛遛，看看谁更适合我们这些搬砖的。

我比较喜欢用Vite + SWC + esbuild这套组合，主要原因就是快。但具体怎么快，和其他方案比到底差多少，这篇文章就来对比一下。主要对比webpack、Vite、Rollup这三家，以及它们各自的优化策略。

webpack vs Vite：开发体验的天壤之别

先说说webpack，这个老大哥我用了好几年，说实话真的很强大，但是开发模式下的编译速度真的是硬伤。特别是项目大了之后，热更新经常要等个几秒，有时候甚至十几秒，简直让人抓狂。

// webpack.config.js - 传统配置
module.exports = {
  mode: 'development',
  devServer: {
    hot: true,
    port: 3000,
    // 即使开了HMR，大项目启动还是很慢
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\/]node_modules[\/]/,
          name: 'vendors',
          chunks: 'all',
        }
      }
    }
  }
}

而Vite就不一样了，ESM的按需加载确实香。首次启动基本秒开，模块热替换也特别快。不过这里有个坑，老项目迁移的时候，有些CommonJS的包可能会有问题，需要额外配置vite-plugin-commonjs。

// vite.config.js - 更轻量的配置
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  server: {
    hmr: true,
    port: 3000,
  },
  optimizeDeps: {
    include: ['some-cjs-package'] // 解决CommonJS兼容问题
  }
})

SWC vs Babel：速度对比超出预期

这个对比让我很意外。Babel我一直觉得够快了，毕竟用了这么久，但是SWC真的快得离谱。同样的TypeScript转译，在一个包含200多个组件的项目中，Babel需要30多秒，SWC只要3秒左右。

// babel.config.js
module.exports = {
  presets: [
    ['@babel/preset-env', { targets: { node: 'current' } }],
    '@babel/preset-typescript',
  ],
}

// swc.config.js - 配置更简洁
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": true
    },
    "transform": null,
    "target": "es2016"
  }
}

不过SWC生态还不够完善，有些插件支持得不好，比如styled-components的一些高级用法就会报错。这个时候我就还是回退到Babel，虽然慢一点但稳定。毕竟项目稳定性比速度更重要。

Tree Shaking：Rollup才是王者

说到Tree Shaking，Rollup真的是鼻祖级别的存在。webpack虽然也支持，但是效果没有Rollup那么激进。我之前用Rollup打包一个UI库，最终体积比webpack少20%左右，这还是在做了各种优化的前提下。

// rollup.config.js - Tree Shaking优化
export default {
  input: 'src/index.ts',
  output: {
    file: 'dist/bundle.js',
    format: 'esm'
  },
  plugins: [
    resolve(),
    commonjs(),
    terser() // 压缩代码
  ],
  treeshake: {
    moduleSideEffects: false // 更激进的Tree Shaking
  }
}

但Rollup的问题也很明显，开发体验不如Vite和webpack，而且对复杂项目的配置支持不够友好。所以我一般只在打包库的时候用Rollup，应用开发还是选择Vite。

缓存策略：影响巨大会让你怀疑人生

这个坑我踩了好几次。正确的缓存配置能让二次构建速度快很多。webpack的持久化缓存需要这样配置：

// webpack缓存配置
module.exports = {
  cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename],
    },
  }
}

Vite这边更简单，默认就有很好的缓存机制，不过要注意NODE_ENV的设置，不然开发环境下缓存可能不会生效。

esbuild的缓存是内置的，基本不用额外配置，这也是它快的原因之一。

我的选型逻辑：看场景，但还是Vite胜出

说说我现在的选择逻辑：

• 新项目：直接Vite + SWC，开发体验最好
• 老项目改造：如果原来用webpack且复杂度不高，升级到webpack5开启持久化缓存
• 库开发：Rollup + Terser，追求最小体积
• SSR项目：Vite + 自定义插件，Vite 2.0之后对SSR支持好了很多

虽然webpack生态更成熟，但是Vite的速度优势太明显了。特别是对于现在的业务开发，时间就是金钱，能快一秒是一秒。

踩坑提醒：Vite的静态资源处理需要注意，public文件夹的资源引用路径和webpack不太一样，迁移的时候容易出问题。

另外，TypeScript的编译也需要单独考虑。我之前用Vite + SWC，TypeScript编译速度确实快，但是类型检查不如tsc准确，所以现在还是会配合typescript插件做类型检查。

以上是我的对比总结，有不同看法欢迎评论区交流

这次对比下来，我觉得编译优化不能一概而论，还是要根据项目实际情况来。Vite确实是趋势，但也不是万能药。老项目迁移成本要考虑，团队学习成本也要考虑。

这个话题还有很多可以挖的，比如CSS处理、图片压缩、代码分割等等，后续有机会再分享一些具体的优化技巧。以上是我踩坑后的总结，希望对你有帮助。