Vite 构建速度优化实战：从配置到性能提升的完整指南

先看效果，再看代码

最近接手一个老项目，用的是 Vue 3 + Vite，但打包后体积大得离谱，首屏加载慢得像在等泡面熟。折腾了几天，把构建时间从 45s 优化到 12s，首屏资源从 4.2MB 压到 1.8MB。今天就把我亲测有效的几招 Vite 优化技巧分享出来，核心代码直接贴，能抄就抄。

别让 node_modules 拖后腿：预构建配置要手动调

Vite 默认会自动预构建（pre-bundle）依赖，但有时候它“聪明反被聪明误”。比如我项目里用了 lodash-es 和 moment，Vite 自动把它们全打进了 vendor chunk，结果光 moment 就占了 600KB。后来我强制把不需要预构建的包排除掉，效果立竿见影。

// vite.config.js
export default defineConfig({
  optimizeDeps: {
    exclude: ['moment', 'lodash-es']
  }
})

但注意，exclude 不是万能的。有些包（比如带 CSS 的 UI 库）如果排除了，反而会导致 HMR 失效或样式错乱。我踩过坑：排除 element-plus 后，开发时按钮样式直接没了。所以建议只对纯 JS 工具库（如 lodash、date-fns）用 exclude。

懒加载路由？别忘了拆分 vendor

很多人以为配了路由懒加载就万事大吉：

// router.js
const Home = () => import('@/views/Home.vue')
const About = () => import('@/views/About.vue')

但实际上，如果所有页面都引用了同一个重型库（比如 echarts），它还是会被打包进主 vendor，导致首屏加载慢。解决办法是：**强制把大库拆成独立 chunk**。

// vite.config.js
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          echarts: ['echarts'],
          pdfjs: ['pdfjs-dist']
        }
      }
    }
  }
})

这样 echarts 就不会污染主 bundle 了。用户进首页时只加载基础逻辑，点到图表页才去拉 echarts。亲测有效，首屏 JS 体积直接少了 300KB。

图片和静态资源：别一股脑全塞 public

以前习惯把所有图片扔进 public 目录，觉得省事。但 Vite 对 public 里的资源不做任何处理——不压缩、不 hash、不 tree-shaking。结果上线后发现，一张 5MB 的 banner 图直接拖垮首屏。

现在我的做法是：小图（<100KB）用 ESM 引入，大图才放 public。Vite 会自动把 ESM 引入的图片转成 base64 或输出到 assets 并加 hash。

<!-- 正确姿势 -->
<template>
  <img :src="logo" alt="logo" />
</template>

<script setup>
import logo from '@/assets/logo.png' // 小图走 ESM
</script>

如果非要放 public，记得自己压缩！我用 sharp 写了个脚本批量处理，省心又省流量。

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

• 别盲目开 sourcemap：生产环境开 sourcemap 会让 bundle 体积翻倍。我之前为了方便调试开了，结果 CDN 流量费暴涨。现在只在 staging 环境开：

  // vite.config.js
    export default defineConfig({
      build: {
        sourcemap: process.env.NODE_ENV === 'staging'
      }
    })

• proxy 配置别写死域名：本地开发用 proxy 代理 API 很常见，但别把域名写死在 vite.config.js 里。否则换环境要改代码。我现在的做法是读取 .env 文件：

  // vite.config.js
    export default defineConfig({
      server: {
        proxy: {
          '/api': {
            target: process.env.VITE_API_BASE_URL,
            changeOrigin: true
          }
        }
      }
    })

• 别忽略 CSS 体积：Vite 默认不压缩 CSS，如果项目用了 Tailwind 或大型 UI 库，CSS 可能超 500KB。记得手动开启 cssMinify：

  // vite.config.js
    export default defineConfig({
      build: {
        cssMinify: true // 默认是 false！
      }
    })

高级技巧：用 analyze 插件揪出大文件

光靠猜哪里大是不行的，必须用工具。我装了 rollup-plugin-visualizer，每次 build 自动生成分析报告：

npm install -D rollup-plugin-visualizer

// vite.config.js
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [
    // ...其他插件
    visualizer({ open: true }) // build 完自动打开报告
  ]
})

跑完 npm run build，浏览器会弹出一个彩色方块图，哪个模块占多大一目了然。上次发现 monaco-editor 居然占了 1.2MB，立马换成按需加载。

这个方案不是最优，但最简单

网上有很多花里胡哨的优化方案，比如自定义 rollup 插件、魔改 esbuild 配置。但我觉得，对大多数项目来说，上面这几招已经够用。毕竟我们不是在参加性能奥运会，而是要快速交付稳定产品。我改完后虽然还有两个小问题（比如某个第三方库的 CSS 重复引入），但无伤大雅，用户感知不到。

以上是我踩坑后的总结，希望对你有帮助。这个技巧的拓展用法还有很多（比如结合 CDN 分发 vendor chunk、动态 import 时加 loading 状态），后续会继续分享这类博客。有更优的实现方式欢迎评论区交流——别光点赞，说说你的实战经验！