小程序开发到一定规模，会遇到包体积的限制。主包超出限制就没法发布，这时候必须做分包。有的项目在不该分包的时候分了，反而带来一堆麻烦。
判断标准是包体积到没到限制，不是功能多不多。
一、什么情况下必须分包
当主包体积接近上限时，就要开始规划。常见触发的情况有几种。功能模块多，每个模块都有自己的页面和组件。用了体积较大的第三方库，比如图表、富文本编辑器、音视频处理。资源文件多，图片、字体、地图资源占了不少。
用户行为也是判断依据。如果一个功能只有少数用户会用到，比如后台管理相关的页面、特定活动的页面，把它们拆出去，主包就轻了。拆出去的部分只有那部分用户会下载，多数用户不受影响。
反过来说，如果包体积还有很大余量，功能也不复杂，就没必要为了分包而分包。分包本身会带来配置上的复杂度，也容易出错。
二、分包的基本思路
把与首页主流程无关的页面拆出去。首页、登录、核心业务流程留在主包，保证用户一进来就能用。活动页、个人中心里的次要功能、帮助文档这类放到分包里。
大体积的依赖单独放。图表库、编辑器这类只在特定页面用的，跟着它所在的页面一起进分包。
还有一种是独立分包，可以做到不依赖主包独立运行。适合那种用户只用一个功能、不需要经过首页的场景，比如扫码直接进的活动页或者核销页。独立分包能把启动速度压得更短。
三、切分包容易出的问题
最常见的是资源路径出错。拆包之后，原本相对路径引用的图片、样式找不到了。这类问题在开发时就能发现，但要注意全面回归测试一遍所有页面。
第二种是公共组件被重复打包。两个分包都用到同一个组件，配置不当会在两边各打一份，包体积不减反增。公共部分要放到主包或者做成公共分包。
第三种是分包之间的跳转限制。分包之间可以直接跳转，但要确认目标分包已经下载。首次跳转时会有下载等待，如果没做加载提示，用户会以为卡住了。跳转前的提示和跳转中的加载状态都要处理。
四、不分包也能减体积的办法
图片外置。把图片放到服务器上，通过网址引用，不打进包里。这一步往往能减掉最多体积，也最容易被忽略。小程序里除了图标和必要的启动图，其他图片基本都可以外置。
检查有没有引入用不到的代码。项目做久了，注释掉的逻辑、废弃的页面、没人用的工具函数会积累不少。清一遍能减掉一部分。
换个更轻的库。同一个功能往往有体积差别很大的实现，比如日期处理、图表展示。选之前先看一下体积。
压缩和去掉冗余资源。图片按实际显示尺寸导出，字体只打包用到的字重，这几项加起来也不少。做减体积之前，先把这几件不用改架构的事做完，往往问题就解决了。