做原生微信小程序时，包体大小是一个很现实的问题。
功能越写越多、图片越加越多、组件越拆越细，最后很容易发现主包变大，冷启动变慢，审核和体验都受影响。
我现在控制小程序包体，主要从几个方面入手。
1. 尽量控制主包内容
主包只放启动必须用到的页面和公共逻辑。
一些低频页面，比如设置页、详情页、活动页、后台入口类页面，可以考虑放到分包里。
这样用户第一次打开小程序时，不需要一次性加载所有内容。
2. 及时做分包
微信小程序支持分包加载，这是控制体积最直接的方式。
我的习惯是：页面只要明显属于某个独立模块，就尽早考虑分包，而不是等到主包快超限再拆。
比如：
- 用户中心
- 商品详情
- 活动页面
- 内容详情
- 管理类页面
- 压缩尺寸
- 使用合适格式
- 删除没用的旧图
- 避免一张图多处重复存放
- 是否有没注册但还存在的页面
- 是否有没引用的组件
- 是否有旧样式文件
- 是否有测试数据和临时文件
这些都适合按模块拆出去。
3. 图片不要直接塞进项目里
图片是包体膨胀最常见的原因。
除非是必须随包发布的小图标，否则大图、内容图、轮播图都应该放到 CDN 或服务器上。
本地图片要注意：
很多小程序包体大，不是代码太多，而是图片管理太随意。
4. 清理无用组件和样式
原生小程序写久了，很容易留下废弃页面、废弃组件和没用的 WXSS。
这些东西单个不大，但积累起来会越来越明显。
每次上线前，我会简单检查：
5. 公共代码不要过度堆积
很多人喜欢把工具函数都放到一个大文件里，最后所有页面都会间接引入一堆不需要的逻辑。
公共代码应该是真的公共，而不是“暂时不知道放哪”。
如果某个方法只有一个模块使用，就放在模块内部即可。
6. 控制第三方库
原生微信小程序不一定需要很多第三方库。
能用原生 API 解决的，就不要随便引入完整库。
尤其是一些只用到一个小功能，却引入一整个工具包的情况，很不划算。
7. 定期看构建结果
不要等到包体超限才开始优化。
开发过程中就应该定期看构建结果，关注主包和分包体积变化。
如果某次提交之后包体明显变大，就及时回头看原因。
总结
小程序控制包体，本质上不是某一个技巧，而是一种开发习惯。
我的优先级是：
1. 主包保持轻2. 能分包就分包3. 图片尽量走远程4. 少引入不必要的库5. 定期清理无用文件
只要这些习惯坚持下来，原生微信小程序的包体一般都能保持在比较健康的范围。