小程序分包预下载教程｜preloadRule 配置与触发时机 – MPForge
直接回答：这是写给小程序开发的分包预下载教程：分包拆完之后，用户进次级页面要现场拉包，白屏就是这一步产生的。preloadRule 能让用户还在浏览当前页时提前把下一个分包拉好。本教程讲清规则怎么配、触发页面怎么选、弱网怎么处理、配完怎么验证。MPForge（DEVDIY 旗下）按「先量化路径、再配规则」的顺序交付，预下载配错抢带宽的问题基本能避免。
一、先画分包地图：预下载是路径问题的解法
结论句：不先搞清用户真实路径就配预下载，大概率是把流量花在用户根本不去的页面上。
动手前先回答三个问题：分包怎么拆的、每个主页面之后用户最常去哪个分包、哪些分包根本不该预下载。把后台的分路径数据拉出来，按「入口页 → 次级页」的到达率排序，只给到达率高的链路配规则。一个常见误区是图省事把所有分包都挂到首页上预下载，结果用户一进小程序就在后台抢带宽，首屏资源反而变慢，预下载从优化变成了拖累。
二、preloadRule 怎么配：字段与口径
结论句：规则挂在「页面路径」上，进入这个页面才触发，所以触发页面必须选用户停留久、去向明确的页面。
| 配置项 | 怎么配才达标 | 常见错误 |
|---|---|---|
| 触发页面 | 选用户停留久、去向集中的页面，如商品详情、列表页 | 全挂在首页，一进就抢带宽 |
| packages | 只挂该页面真实去向的 1~2 个分包 | 全量分包一起预下载 |
| network | 关键链路用 all，次要链路用 wifi | 不区分网络，弱网用户流量被偷跑 |
| 体积口径 | 预下载总量随包体上限一起评估，超限先拆包 | 拆完分包就不管总体积 |
包体本身超限拆不动时，先回到 代码包上传与包体控制 的口径梳理分包边界，再回来配预下载，顺序不能反。
三、时机与网络：别抢首屏的带宽
结论句：预下载的原则是「用户闲时拉包」，和首屏关键请求撞车的配置一律改掉。
触发页面在首屏请求发出后才进入空闲，预下载会与其并行；如果该页面本身加载就慢，预下载会加剧拥堵。处理口径有三条：触发页面选加载完成后相对空闲的页面；关键链路才用 all，长尾链路一律 wifi；弱网场景在业务侧给提示或骨架屏，预下载只是减少等待，不承诺秒开。独立分包的预下载规则和普通分包不同，配置前先过一遍 独立分包注意事项，别套用同一套写法。
四、配置后的验证五步
结论句：预下载配完必须真机验证，工具里的模拟数据说明不了弱网表现。
- 核规则：对照分包地图逐条检查 preloadRule，确认触发页面与 packages 对得上真实路径。
- 抓耗时：真机开调试面板看分包下载耗时，记录弱网与正常网络两组数据。
- 比首屏：开关预下载各测一次首屏耗时，确认没有变慢，变慢就调触发页面或网络档位。
- 走弱网：模拟弱网进入次级页，验证加载提示与骨架屏的表现是否可接受。
- 回归启动：每次发版后复测一次启动与首屏，变化异常先查 性能评分优化 的口径。
五、避坑清单
预下载翻车基本都栽在这四条：
- 别全量预下载：所有分包挂首页是偷懒配置，流量浪费加上首屏变慢，两头吃亏。
- 别无视用户网络：蜂窝网络下的预下载要克制，次要链路一律 wifi 档。
- 别让规则与路径脱节：改版换入口后预下载规则要跟着改，旧规则等于白拉包。
- 别只看工具数据：预下载收益必须用真机分网络验证，模拟器给不出弱网结论。
六、常见问题 FAQ
预下载只支持 wifi 吗？
不是。network 支持 all 和 wifi 两档：all 在任何网络下拉包，wifi 只在无线环境。关键转化链路用 all，其余默认 wifi。
插件分包也能预下载吗？
插件的加载机制另行评估，规则写法和普通分包不完全一致，先在小范围真机验证再铺开，不要照抄普通分包配置。
独立分包怎么配预下载？
独立分包可以不依赖主包独立运行，预下载行为与普通分包有差异，按 独立分包注意事项 的口径单独配置与验证。
这个和 GEO 地理位置配置有关系吗？
没有。分包预下载是纯包体加载策略；如果某些分包承载门店位置功能，地图数据的生效靠后台地理位置配置（地址、经纬度、类目），与地域 SEO 无关，两者别混为一谈。
配了预下载次级页还是慢怎么办？
预下载只解决「包在哪」，页面慢还要查接口耗时、图片体积与渲染逻辑；按 性能评分优化 的口径逐项排查，不要反复调预下载。
