分包与包体策略
分包不是“项目很大以后再做”的事情。 对于大多数小程序项目，它通常都会比你想象中更早出现。
为什么分包几乎是必修课
因为你很快就会同时遇到这几类压力：
- 首屏包体不能无限增长
- 某些业务只在低频场景出现
- 页面和组件并不是都应该跟着首页一起下载
例如一个常见商城项目：
txt
主包：
- 首页
- 搜索
- 商品详情
- 登录态判断
订单分包：
- 订单列表
- 订单详情
- 售后页
营销分包：
- 优惠券
- 活动会场
- 积分商城一条对新用户最实用的原则
把“用户一打开 App 最可能立刻访问的页面”留在主包。 把“进入后续流程才会访问的业务模块”逐步拆到分包。
一个简单的拆分例子
假设你现在有这些页面：
txt
pages/
├─ home/index
├─ search/index
├─ goods-detail/index
├─ order-list/index
├─ order-detail/index
└─ after-sale/index推荐先这样想：
home/search/goods-detail留主包order-list/order-detail/after-sale考虑归到订单分包
分包不只是路由问题
真正做分包时，你还要同时考虑：
- 页面路径放在哪
- 页面依赖的组件放在哪
- 页面依赖的图片和静态资源放在哪
- 主包和分包之间有没有不合理引用
例如一个很典型的坏味道是：
- 订单分包页面依赖一个只能在主包里的大组件
- 或者订单分包页面引用了主包私有资源路径
这样很容易在构建和运行时都出现问题。
一个更稳的组织方式
txt
src/
├─ pages/
│ ├─ home/
│ └─ goods-detail/
├─ subpackages/
│ └─ order/
│ ├─ list/
│ ├─ detail/
│ └─ after-sale/
├─ components/
│ ├─ shared/
│ └─ home/
└─ assets/你要尽量做到：
- 主包页面依赖主包组件或共享组件
- 分包页面优先依赖分包内部组件或真正的共享组件
- 资源尽量跟着实际使用场景走
怎么判断“现在该不该开始分包”
下面这些信号一出现，就值得开始规划：
- 首屏加载明显变慢
- 某些业务页根本不属于用户首次访问路径
- 构建后包体越来越大
- 团队开始因为“放哪一页”争论不清
新用户最容易踩的 4 个坑
1. 把主包当成无限容量
结果首页不断变重，最后什么都想塞进去。
2. 分包只拆页面，不拆依赖
页面路径拆出去了，但组件和资源依赖还在主包，实际收益很有限。
3. 共享组件没有真正共享边界
看起来是“共享”，实际上里面偷偷依赖某个主包页面环境。
4. 只看构建成功，不看真实加载体验
分包是否做对，最终还是要在开发者工具和真机里验证加载路径与体验。
一份足够实用的分包检查清单
txt
[ ] 主包只保留首屏高频页面
[ ] 分包按业务域拆，不按“随便找个目录”拆
[ ] 分包页面依赖的组件和资源布局清晰
[ ] 共享组件不偷偷依赖特定包环境
[ ] 构建成功后做过真实页面跳转验证你接下来最适合继续看：