必须手动定位真实体积来源，执行npm run build:mp-weixin后打开unpackage/dist/build/mp-weixin目录按大小排序查>500kb的.js/.png文件，重点检查pages/、components/、static/及common/vendor.js，并用代码依赖分析确认内容。

主包超 2MB 不会报错，只在微信开发者工具上传时静默拦截——必须手动定位真实体积来源，否则所有优化都是蒙眼打靶。

怎么看哪个文件真正在撑大主包

别信 HBuilderX 构建日志里那句“构建完成”，它不反映产物大小。真正有效的路径是：

• 执行 npm run build:mp-weixin 后，打开 unpackage/dist/build/mp-weixin 目录
• 右键 → “在资源管理器中打开”，对 pages/、components/、static/ 子目录按大小排序
• 重点盯 >500KB 的 .js 或 .png 文件；common/ 下的 vendor.js 尤其要查（常见 1.8MB+）
• 用微信开发者工具打开「代码依赖分析」，直接看 vendor.js 里塞了什么——比如 uView 全量、echarts 完整版、未压缩字体

为什么图片搬去 CDN 体积还不变

外部化不是把文件拖到服务器就完事。只要代码里还用 require()、import 或相对路径引用，Webpack 就照常打包进去。

uni-app

uni-app 是基于 Vue 的跨端开发框架，适合开发 H5、App、小程序、鸿蒙和多端业务应用。

下载

• 图片必须写死绝对 HTTPS URL：<image :src="'https://cdn.example.com/logo.png'>，禁用 require('@/static/logo.png')
• CSS 中字体要用 @font-face { src: url('https://cdn.example.com/font.woff2'); }，不能放 static/fonts/ 再 @import
• 背景图同理：background-image: url('https://cdn.example.com/bg.jpg');，带变量拼接（如 url(${cdn}/a.png)）也会触发全量打包
• 所有通过 v-bind:style、import、require 引用的资源，只要路径可静态解析，就进包

分包配置后主包反而更大了怎么办

核心陷阱是：被多个分包引用、但主包完全没用的模块（如 utils/request.js），uni-app 默认提至主包 common/vendor.js。

• 必须在 manifest.json 的 mp-weixin 节点下启用两项开关："subPackages": true 和 "runtimeCompress": true
• 检查 pages.json 的 subPackages 数组是否漏写了某个新页面路径——漏写 = 归入主包
• 主包里放的组件如果被分包页面 import，默认会提至主包；想避免，就用 import() 动态引入，或把组件挪进对应分包目录
• 禁用 preloadRule 的通配符配置（如 "*" 或 "pages/**"），否则目标页面 JS/WXML/WXSS 会被强行拉进主包缓存

第三方依赖怎么砍掉无效部分

很多体积超标来自全量引入的重型库，而不是业务代码本身。

• 用 dayjs（2KB）代替 moment.js（20KB+）；用 lodash-es 按需引入代替完整 lodash
• UI 库必须按需：比如 uView 或 uni-ui，只注册用到的组件，别 import uView from 'uview-ui' 全量引入
• 检查 package.json，把开发期用的库（如 mockjs、eslint）移到 devDependencies 或直接删掉
• 某些插件内部数据可删减（如 uView 的 libs/util 里未使用的 JSON 数据），删掉后体积立降

最关键的一步往往被跳过：不打开 unpackage/dist/build/mp-weixin 看真实文件大小，所有“我优化了”的判断都是假设。体积问题不是靠删逻辑，而是靠看产物、改引用、调配置三者闭环验证。