说实话，当你辛辛苦苦开发完一个功Neng完备的中后台管理系统，满怀期待地敲下 npm run build，结果终端里跳出一个刺眼的 dist 30MB 时那种心情简直比发现代码里全是 Bug 还要崩溃。30MB？这哪里是打包，这简直是在搬运整个 Node_modules！用户打开你的页面kan着那个转圈圈的 Loading，估计心里Yi经在骂娘了。

别慌，这其实是hen多前端项目在成长过程中dou会遇到的“肥胖期”。Vite 虽然以快著称，但Ru果你不懂得调教它，它照样会给你塞回来一堆臃肿的产物。今天我们就来一场外科手术式的瘦身实战，kankan怎么把那个虚胖的 30MB 项目，硬生生压缩到 800KB 以内，甚至geng小。这不仅仅是数字游戏，geng是对用户体验的极致尊重。

第一步：诊断——别盲目开刀，先拍个片子

在动手优化之前，Zui忌讳的就是“凭感觉”。你觉得某个组件大，结果可Neng只是冰山一角。我们需要一把手术刀，或者说一个透视镜。这时候，rollup-plugin-visualizer 就派上用场了。这玩意儿就像是 Vite 的 X 光机，Neng让你一眼kan穿打包产物的内部结构。

安装它非常简单，不需要复杂的配置：

npm install rollup-plugin-visualizer -D

接着，在你的 vite.config.ts 里稍微加一点料：

// vite.config.ts
import { defineConfig } from 'vite'
import { visualizer } from 'rollup-plugin-visualizer'
export default defineConfig({
  plugins: 
})

当你 构建完成，它会自动弹出一个浏览器页面。相信我，那个页面会让你大开眼界。你会惊讶地发现，原来 node_modules 才是真正的“体积黑洞”，尤其是那些庞大的 UI 库和图表库，它们正肆无忌惮地吞噬着你的带宽。有了这张“地图”，接下来的优化就有了明确的方向。

第二步：拆分策略——拒绝一锅乱炖

hen多时候，体积大是因为我们把所有东西dou塞进了一个文件里。用户明明只需要访问首页，你却逼他下载了后台管理系统的所有逻辑。这显然是不合理的。我们需要利用 Vite强大的 manualChunks 功Neng，把代码拆得细一点，再细一点。

1. 基础分包：把“常客”和“过客”分开

Zui简单的策略，就是把业务代码和第三方库分开。第三方库geng新频率低，Ke以长期缓存；而业务代码天天变。混在一起的话，改一行代码，用户就得重新下载 Vue，太浪费了。

// vite.config.ts
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          'vue-vendor': ,
          'ui-vendor': ,
          'utils-vendor': 
        }
      }
    }
  }
})

2. 进阶拆分：精细化控制

Ru果你对体积有洁癖，甚至Ke以针对特定的库进行geng细致的拆分。比如 Ant Design Vue 这种巨无霸，我们Ke以把它单独拎出来或者按模块拆分。不过要注意，拆得太碎会导致 HTTP 请求数激增，在 HTTP/1.1 环境下可Neng适得其反，但在 HTTP/2 多路复用的环境下这反而是个优势。

第三步：按需引入——只拿你需要的

这绝对是体积优化的“核武器”。hen多开发者习惯性地全量引入库，比如 import _ from 'lodash'，这一下子就干进去了 70KB。但实际上你只用了一个 cloneDeep，这简直是暴殄天物。

1. Lodash 的救赎

请立刻抛弃 lodash，拥抱 lodash-es。后者是 ES Module 版本，配合 Tree Shaking，Neng实现真正的按需打包。

// ❌ 错误示范：全量引入，约 70KB
import _ from 'lodash'
const result = _.cloneDeep
// ✅ 正确姿势：按需引入，约 13KB
import { cloneDeep } from 'lodash-es'
const result = cloneDeep

2. UI 组件库的自动魔法

手动引入 UI 组件虽然Neng减小体积，但写起来太累了而且容易漏掉样式。这时候，unplugin-vue-components 和 unplugin-auto-import 这对神器就该登场了。

它们Neng帮你自动引入组件和 API，你只管在代码里用，插件会自动帮你把 import 语句加进去，并且只打包你用到的部分。

// vite.config.ts
import Components from 'unplugin-vue-components/vite'
import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'
export default defineConfig({
  plugins: ,
      extensions: ,
      // 自动生成组件声明文件
      dts: 'src/components.d.ts',
      resolvers: 
    })
  ]
})

配置好后你在模板里直接写 ，打包时它就只会把 Button 组件的代码塞进去。Element Plus 这种原本几百 KB 的库，Zui后可Neng只剩下几十 KB。这感觉，简直像是在大减价时抢到了限量版。

3. ECharts 的瘦身秘籍

图表库 ECharts 也是体积大户。全量引入直接 600KB+ 起步。正确的Zuo法是按需引入核心和组件。

// src/utils/echarts.ts
import * as echarts from 'echarts/core'
// 只引入你需要的图表类型
import { BarChart, LineChart } from 'echarts/charts'
// 引入需要的组件
import { 
  TitleComponent, 
  TooltipComponent, 
  GridComponent 
} from 'echarts/components'
// 引入渲染器
import { CanvasRenderer } from 'echarts/renderers'
echarts.use()
export default echarts

第四步：资源压缩——榨干每一滴水分

代码写好了拆分也Zuo好了还Neng再挤一挤吗？当然Ke以。通过压缩算法，我们Ke以把文本资源变得geng小。

1. Gzip 和 Brotli

这是服务器端和构建端配合的戏码。Vite Ke以在构建时直接生成 .gz 和 .br 后缀的压缩文件。服务器检测到浏览器支持压缩，就会直接扔过去这些压缩包，体积Neng减少 60%-70%！

npm install vite-plugin-compression -D

// vite.config.ts
import viteCompression from 'vite-plugin-compression'
export default defineConfig({
  plugins: 
})

2. 图片优化

别光盯着 JS，图片也是大头。现在的 Web 项目，高清图随便几张就是几 MB。使用 vite-plugin-imagemin 或者 unplugin-imagemin Ke以在构建时自动压缩图片，甚至把 PNG 转成体积geng小的 WebP。

不过要注意，国内网络环境安装这些依赖的 C++ 模块经常报错。Ru果遇到问题，记得把 npm 源切到淘宝镜像，或者在 package.json 里配置一下 bin-wrapper 的路径。

第五步：CDN 加速——借力打力

有些库实在太大了或者用户访问你的网站时浏览器缓存里Yi经有了这些库。这时候，利用 CDN 外部引入是个极好的选择。

通过 vite-plugin-cdn-import，我们Ke以把 Vue、Axios 这些常用库从打包产物中剔除，改为从 CDN 加载。

// vite.config.ts
import { Plugin as importToCDN, autoComplete } from 'vite-plugin-cdn-import'
export default defineConfig({
  plugins: 
    })
  ]
})

这样Zuo的好处显而易见：你的主包体积瞬间减小，而且利用了 CDN 的边缘节点加速。当然风险也是有的，万一 CDN 挂了你的页面也就废了。所以这招要慎用，通常只用于那些极度稳定、版本geng新不频繁的库。

第六步：开发体验与构建速度的平衡

我们聊了太多体积，其实 Vite 的核心优势是快。Ru果为了优化体积导致构建慢如蜗牛，那也是得不偿失。

1. 依赖预构建

Vite 在开发时会预构建依赖，把 CommonJS 转成 ESM。Ru果你的项目启动变慢了检查一下 optimizeDeps 配置。把那些不经常变动的依赖显式加进去，Ke以让 Vite 跳过耗时的依赖分析。

// vite.config.ts
export default defineConfig({
  optimizeDeps: {
    include: ,
    exclude:  // 某些库可Neng不需要预构建
  }
})

2. 关闭 SourceMap

在生产环境构建时除非你要排查线上的错误，否则一定要把 sourcemap 关掉。它不仅会增加体积，还会暴露源代码结构。

// vite.config.ts
export default defineConfig({
  build: {
    sourcemap: false // 默认就是 false，确保没被误开
  }
})

一套完整的配置方案

说了这么多，Zui后给大家整理一份“集大成者”的配置文件。把上面提到的策略整合起来这就是你通往 800KB 世界的钥匙。

// vite.config.ts
import { defineConfig, loadEnv } from 'vite'
import vue from '@vitejs/plugin-vue'
import { resolve } from 'path'
import Components from 'unplugin-vue-components/vite'
import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'
import AutoImport from 'unplugin-auto-import/vite'
import viteCompression from 'vite-plugin-compression'
import { visualizer } from 'rollup-plugin-visualizer'
import { Plugin as importToCDN, autoComplete } from 'vite-plugin-cdn-import'
export default defineConfig => {
  const isProduction = mode === 'production'
  return {
    resolve: {
      alias: {
        '@': resolve
      }
    },
    plugins: ,
        dts: 'src/auto-imports.d.ts'
      }),
      // 自动导入组件
      Components({
        dirs: ,
        dts: 'src/components.d.ts',
        resolvers: 
      }),
      // 生产环境才开启的插件
      isProduction && visualizer,
      isProduction && viteCompression,
      isProduction && viteCompression,
      // CDN 引入
      isProduction && importToCDN({
        modules: 
      })
    ].filter,
    build: {
      // 关闭 sourcemap
      sourcemap: false,
      // 提高 chunk 大小警告阈值
      chunkSizeWarningLimit: 1000,
      rollupOptions: {
        output: {
          // 分包策略
          manualChunks: {
            'vue-vendor': ,
            'element-plus': ,
            'utils': 
          },
          // 文件命名
          chunkFileNames: 'static/js/-.js',
          entryFileNames: 'static/js/-.js',
          assetFileNames: 'static//-.'
        }
      }
    }
  }
})

优化是一场持久战，没有一劳永逸的银弹。随着项目的迭代，新的依赖会被引入，新的代码会产生垃圾。保持定期审视打包产物，保持对体积的敏感度，这才是优秀前端工程师的职业素养。现在去试试吧，kan着那个 800KB 的数字，你会感谢现在努力的自己。

---