一、生产环境Electron安装包膨胀的真实痛点

上周我们团队做新版应用上线前测试，发现原本200多MB的安装包，居然涨到了520多MB。运维同学说CDN节点同步这个包的时间比之前多了3倍，之前1分钟就能全节点拉完，现在要3分多钟。用户反馈也多了：安装时卡很久，启动后内存占用比旧版多了近一倍，还有几个测试用户反映“安装包太大，不想下载”。更麻烦的是，后来查原因，发现是新版本加了一个日志库，和之前内置的日志模块重复了，多了12MB，还有一些没用的小图标、测试文件混在包里，加起来有几十MB。这种情况很多中小Electron开发团队都遇到过，一开始没在意，到后期版本迭代多了，包体积就像吹气球一样越来越大，最后变成分发的负担。

二、Electron安装包瘦身的分层落地方案

这个方案是我们踩了几次坑后沉淀的，从三个层面入手，从根源减少体积，每个层面都有可直接抄的配置。

2.1 依赖层面：砍掉重复和没用的依赖

很多时候包大，是因为装了整个npm包，但只用到其中一小部分。比如我们用的lodash工具库，只需要排序和取最值的功能，但整个库有几百KB；还有的包是重复依赖，比如同一个库被多个功能引入，打包时会重复算体积。

示例配置：Electron打包工具electron-builder的依赖裁剪

技术栈：Electron + Vue3 + electron-builder

{
  "build": {
    "asar": true, // 把代码打包成一个asar文件，减少小文件的开销，相当于把很多小文件合并成一个大文件，不用一个个加载
    "asarUnpack": [
      // 这里写要排除的依赖，比如某个没用的测试库，或者只有Windows才用的库，用通配符匹配
      "node_modules/unused-test-lib/**",
      "node_modules/win-only-lib/**"
    ],
    "files": [
      "dist/**/*", // 只放前端构建后的产物，排除开发时的源码
      "package.json" // 必须的配置文件
    ]
  }
}

这个方法的优点是操作简单，只要搞清楚每个依赖的用途，不用改太多代码；缺点是如果写错路径，比如把核心依赖排除了，应用就会报错。注意事项：先查package.json里的每个依赖，用工具看自己用到了多少，不确定的先留着，测试没问题再删，每次改完都要跑一遍主流程功能，比如登录、保存文件，确保没出错。

2.2 资源层面：压缩前端的静态文件

前端项目里的图片、CSS、JS这些静态资源，占了包体积的很大一部分，比如一张几MB的原图，压缩后可能只有几百KB，代码里的调试注释和空格，去掉后也能省不少空间。我们用的Vue项目，平时开发时用的资源很多没优化，打包时统一处理就行。

示例配置：用Vite压缩静态资源

技术栈：Electron + Vue3 + Vite

// vite.config.js 前端构建配置
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
// 这个插件能帮我们分析打包后的文件，找到哪些文件太大
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [
    vue(),
    // 打包后生成一个stats.html文件，打开就能看到所有依赖的体积，一目了然
    visualizer({ open: false, filename: 'stats.html' })
  ],
  build: {
    // 压缩JS和CSS代码，去掉空格、注释和没用的调试代码
    minify: 'esbuild',
    // 删掉console.log和debugger，打包后不会保留，既压缩体积也更安全
    terserOptions: {
      compress: {
        drop_console: true,
        drop_debugger: true
      }
    },
    // 小于4KB的图片转成base64格式，不用单独加载，减少请求和体积
    assetsInlineLimit: 4096,
    rollupOptions: {
      output: {
        // 把第三方依赖单独打包成一个文件，避免和自己的代码混在一起，也能让包更小
        manualChunks(id) {
          if (id.includes('node_modules')) {
            return 'vendor' // 所有npm里的依赖都放到vendor.js里，不会重复
          }
        }
      }
    }
  }
})

这个方法的场景是：项目里有很多未优化的图片，或者代码里留了很多调试的console，适合所有前端Electron项目。优点是见效快，压缩完JS和图片通常能省100MB以上；缺点是图片压缩太狠会模糊，代码压缩不会影响功能，但要选合适的压缩级别，注意事项：用插件压缩图片时，把质量设到80左右，平衡体积和清晰度；拆分依赖的时候，不要拆太多小文件，否则反而会增加加载时间。

2.3 构建层治理：优化Electron的打包规则

Electron打包时默认会带上所有平台的资源，比如你打Windows包，会不小心带了Mac和Linux的资源，还有Electron本身的核心库，旧版本的体积比新版本大，所以选对打包的规则和版本也很重要。

示例配置：electron-builder的平台和版本优化

技术栈：Electron + Vue3 + electron-builder

{
  "build": {
    // 只打我们需要的Windows64位包，不用打全平台，体积直接减少一半
    "win": {
      "target": "nsis", // 安装包类型，NSIS是Windows常用的，稳定
      "arch": ["x64"] // 只打64位，不用打32位，除非有大量用户用32位
    },
    // 用国内的Electron镜像，下载更快，也避免下载多余的版本
    "electronDownload": {
      "mirror": "https://npm.taobao.org/mirrors/electron/",
      "version": "28.0.0" // 固定Electron版本，避免自动下载测试版，保证稳定性
    },
    "appId": "com.yourteam.appname" // 应用唯一标识，必须填，否则打包会出错
  }
}

这个方法的场景是：团队的用户主要集中在某个平台，比如国内都是Win64，就不用打其他平台的包；或者之前用的Electron旧版本，体积大，换最新稳定版后体积会明显减小。优点是直接减少打包的冗余，配置简单；缺点是如果需要给其他平台的用户，还要单独打包，注意事项：先查自己的用户分布，比如Mac用户占10%，那就要留Mac的打包配置，不要全删；Electron版本选长期支持版（LTS），稳定性好也优化了体积。

三、瘦身方案的验证和效果

我们把上面的配置改完后，打包后的体积从520MB降到了210MB，足足减了310MB，减少了近60%。测试了一周，功能没出问题，CDN下载时间从3分钟降到了1分钟，安装时间从25秒降到了8秒，用户反馈里再也没有“安装包太大”的吐槽，运维的带宽成本也降了近40%。

四、瘦身的注意事项

  1. 先分析再动手：每次改之前，先看打包后的依赖分析图，找到最大的几个文件，优先砍最大的，不要乱删；
  2. 每步都测试：改完配置后，必须全流程测试，比如登录、打开文件、保存设置这些核心功能，确保没出错；
  3. 版本管理：把瘦身的配置存在git里，每次迭代都记录，方便回滚；
  4. 持续优化：每次加新功能，都要检查有没有加多余的依赖，比如加日志功能，就用轻量的日志库，不要用大的；

五、总结

Electron安装包膨胀不是一天形成的，靠单一方法很难减下来，我们的分层方案从依赖、资源、构建三个层面入手，每个层面都有具体的配置和注意事项，适合中小团队落地，不需要复杂的工具，都是常用的打包工具的配置，能快速解决分发负担的问题，提升用户体验。