必须手动定位真实体积来源，执行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 就照常打包进去。
- 图片必须写死绝对 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 看真实文件大小，所有“我优化了”的判断都是假设。体积问题不是靠删逻辑，而是靠看产物、改引用、调配置三者闭环验证。
