提审前一晚，开发在群里发了一句：主包超过2兆，传不上去。翻了一遍工程，光图片素材就占了一半，还有两个压箱底的第三方组件库根本没用到。微信小程序开发的包体积限制是硬门槛，瘦身这件事越早规划越省事，临上线才动手就得熬夜了。
先把体积规则搞明白
小程序的主包上限是2兆，加分包后整体上限可以到30兆。主包必须放启动必需的页面和公共资源，其他业务模块拆进分包，用户访问到对应页面时才下载。独立分包还能脱离主包单独启动，适合活动页这类相对独立的功能。项目立项时就把分包边界画好，比后期拆库迁代码的代价小得多，这是架构层面十分钟的决定，能省掉后期几天的返工。
按性价比排瘦身顺序
瘦身从性价比最高的下手。第一刀砍图片：大图全部上CDN，本地只留图标和小图，一张没压缩的banner图就能占几百K。第二刀砍字体：中文字体动辄几兆，用字体子集化工具只保留实际用到的字符，或者干脆用系统字体。第三刀清依赖：检查引用了却没使用的组件库、样式库，构建配置里开启压缩和按需引入。
- 大图转CDN，本地只留必要图标
- 字体子集化或改用系统字体
- 清理无用依赖，开启代码压缩
瘦完身别忘了首屏
分包会带来分包下载的等待，配合预下载配置可以提前拉取大概率会被访问的分包，比如首页推荐位通向的详情页。加载过程用骨架屏过渡，比白屏转圈体验好一大截。包体积和首屏体验是一件事的两面，别只顾着把包塞小，加载节奏也要排好，用户感知的快慢是两者叠加的结果。
两条建议：把包体积检查放进每次发版的固定动作，占用超过七成就预警处理；新项目开工时让比格网络这类有经验的服务商先出分包规划，后期省下的全是返工时间。清依赖时用构建分析工具看每个包的占比，凭感觉删很容易删错重点。分包边界画在业务模块之间最稳，页面之间的公共组件留主包，别为了塞得下把公共代码复制两份。补充一个数字感受：把主包从两兆压到一点二兆，4G环境下的启动下载大约省零点四秒，用户未必说得出来，但留存数据里能看到差别。微信小程序开发的性能账都是这样，单笔看着小，累加起来就是竞品和你拉开体验差距的地方，每次发版把包体积记录下来，趋势比单次数值更能暴露问题。包体积是体验的地基，值得常看常紧。
