主包超2MB时应优先排查误入内容并启用分包优化。需用代码依赖分析定位冗余资源，配置subPackages和runtimeCompress，对echarts、uView按需引入，静态资源全部移出主包。
主包超2MB时，先确认哪些文件被错误打入主包
主包体积超标，90%的情况不是代码写得太多，而是不该进主包的东西进去了。微信开发者工具的「代码依赖分析」必须第一时间打开——它能直接告诉你 vendor.js 里塞了什么、哪个组件占了 800KB、哪张图片被编译进了 static/ 目录却没走 CDN。
常见误入主包的几类内容：
-
utils/下的工具函数被多个分包引用，UniApp 默认提至主包（哪怕你写了分包配置） -
components/根目录下放了 uView 或 uni-ui 的全量组件，哪怕只用了uni-button，整个 UI 库仍被打进主包 -
static/fonts/里的 .woff2 字体文件未压缩，单个就 600KB+ -
pages.json中漏配某个新页面，导致它默认归入主包
启用 subPackages + runtimeCompress 是最硬核的起步动作
别跳过这步——很多项目卡在 2.1MB 就停住，其实只是没开分包优化开关。在 manifest.json 的 mp-weixin 节点下，必须同时配齐这两项：
{
"mp-weixin": {
"optimization": {
"subPackages": true,
"runtimeCompress": true
}
}
}
注意：runtimeCompress 不是“压缩图片”，而是移除 JS 中的注释、空格、未使用的调试逻辑，实测可减 1.2–1.8MB；subPackages: true 才能让分包 JS 不再塞进 vendor.js。二者缺一不可。
容易踩的坑：
- HBuilderX 里勾选「运行时是否压缩代码」只是开发阶段模拟，不生效于正式构建，必须靠
manifest.json配置 - 开启后若出现分包页面白屏，大概率是某分包内用了主包未提供的 polyfill（比如 Promise），需手动在分包入口加
import 'es6-promise/auto'
echarts、uView 等重型库必须按需加载或替换
echarts 完整版 2.1MB，但业务中通常只用柱状图+折线图，根本不需要地理坐标、3D 渲染、SVG 导出等模块。直接引入 echarts 全量包，等于主动往主包塞炸弹。
可行方案：
- 改用
echarts-for-weixin官方精简版（仅含基础图表，约 350KB） - 用
echarts@5.4.3+webpack别名，定向 alias 到echarts/lib/chart/bar和echarts/lib/component/toolbox等最小路径 - 更激进：把图表逻辑抽成独立分包，主包只留骨架，分包内再 import echarts —— 这样主包彻底不沾边
- uView 同理：不要
import uView from 'uview-ui'，改用import { uniButton } from 'uview-ui/components/uni-button/uni-button.vue'
静态资源必须脱离主包，尤其是图片和字体
一张未压缩的 1080p PNG 图片可能达 1.2MB，而主包里藏了 5 张这种图，就直接爆限。这不是优化问题，是工程规范问题。
执行动作清单：
- 所有
static/img/下图片，全部上传 CDN，本地只留占位符或删掉；src属性统一改为https://cdn.example.com/xxx.png - ≤20KB 的图标，用 HBuilderX 右键「转换为 base64」，嵌入 CSS 或内联 style，避免请求开销
- 字体文件（.woff2/.ttf）一律转为 iconfont 在线服务，或用
@font-face指向 CDN，禁止放入static/fonts/ - 音频/视频资源绝不放本地，改用云点播 URL +
<video src="">加载
最后提醒一句：分包不是万能解药。如果主包里还堆着 3 个未拆分的业务模块、2 套重复工具函数、1 套全量图标字体，再怎么配 subPackages 也救不回来——真正要动刀的，永远是人写的代码结构，而不是 build 配置。
