4.5 分包加载与预加载

4.5 分包加载与预加载

本节导读：包体积是小程序端的刚性约束，分包是官方给出的正解。本节讲 subPackages 的拆包策略与体积红线、preloadRule 的时机配置，对照 App 端与 H5 端的差异，最后给出商城三十页的完整分包方案与一次"白屏抢救"的实战复盘。

体积红线逼出的包结构设计

微信小程序的红线要背下来：主包（含独立分包外的一切）上限约两兆，单个分包上限两兆，总体积上限二十兆。商城的功能全塞主包必然爆表，分包于是不是优化项而是必答题。分包在 pages.json 里声明，每个分包有自己的 root 与 pages：

{
  "pages": [
    { "path": "pages/index/index" },
    { "path": "pages/goods/detail" }
  ],
  "subPackages": [
    {
      "root": "pagesOrder",
      "pages": [
        { "path": "submit/submit" },
        { "path": "result/result" },
        { "path": "list/list" }
      ]
    },
    {
      "root": "pagesActivity",
      "pages": [
        { "path": "seckill/seckill" },
        { "path": "lottery/lottery" }
      ]
    }
  ],
  "preloadRule": {
    "pages/goods/detail": {
      "network": "all",
      "packages": ["pagesOrder"]
    },
    "pages/index/index": {
      "network": "wifi",
      "packages": ["pagesActivity"]
    }
  }
}
​

分包内页面的跳转 url 用完整路径（斜杠加分包 root 加页面路径），写法与主包页面无异——分包对业务代码几乎是透明的，这正是它工程价值高的原因。static 目录跟着主包走，各端通用的图片素材是主包膨胀的头号推手：把大图移到网络、分包专属素材放进分包目录（编译器会归拢到对应分包产物），两条手段用完主包通常能瘦回红线内。

拆包的切法：按动线不按文件夹

分包切在哪，决定加载体验。原则一句话：按用户动线切，让一次任务所需的页面聚在同一包里。商城的切法：下单全流程（确认、支付、结果、订单列表）聚在 pagesOrder，用户从详情进下单时整包一次到位；营销活动聚在 pagesActivity，低频但重（抽奖组件、动画素材），不拖累主包下载。反例也要记：把"确认订单"放主包而"支付结果"放分包，用户提交订单的瞬间才拉分包，弱网下就是一次白屏——动线上的关键节点宁可多花心思归拢，也别让分包边界横在流程中间。

preloadRule：让包在用户到达前到位

preloadRule 的语义是"用户停留在某页时，替他预下载某些分包"。两个参数各有一套判断：network 填 wifi 是只在天候好时预载（营销类大包的稳妥选择），填 all 则不惜流量（下单主动线就该 all）；packages 列出要预载的分包 root。配置的隐含契约是时机跟着页面走：用户浏览详情页时预载订单包，等他点"立即购买"，包大概率已经就位。预载不是越激进越好——全部 all 等于变相全量下载，运营商与用户流量都不感激你；商城的分工是主动线 all、活动线 wifi。

图 4-5 商城分包结构与预载时机

端差异与一次白屏抢救

分包语义在端间并不等值。H5 端分包编译为按需加载的代码块，效果接近路由级懒加载，没有硬性体积红线；App 端 vue 页面整包进安装包，分包更多是工程组织的意义，真正按需的是 nvue 与 wgt 热更资源。这套差异决定测试策略：分包相关问题只在微信端做真机验证，别用 H5 顺手的通过就推定微信端没问题。

实战复盘收尾。商城上线前夜的"白屏抢救"：审核同学反馈进订单列表偶发白屏。定位发现订单列表被切在一个新拆的分包里，而入口配置的预载规则写错了 root 名称，等于没预载；弱网真机复现，点进列表时分包还在下载。修复两步——修正 preloadRule 的 packages 名称、列表骨架屏兜底（分包未就位时先渲染占位）。教训提炼成一句公约：预载规则上线前用真机弱网验证一次，包结构图上的箭头只有跑在真实网络里才算数。

主包 vendor 的治理经验

分包之后体积告警仍可能来自主包，源头常常是 vendor：公共依赖默认打进主包的公共块，一个重量级工具库被主包页面引用，全端产物就都背上它。治理思路两条：轻量替代，把只在个别分包使用的库下沉到分包目录内引用，配合构建分析确认它移出了公共块；能删则删，检查依赖清单里"当年引了现在没人用"的包，这类清理几乎每个老项目都能捡到几百 KB。分析工具用各端构建自带的产物体积报告，微信开发者工具的代码依赖分析也直观可用。把"主包体积看板"放进每周例会，红线问题就停在萌芽期。

包结构变更的发布纪律

分包结构不是一劳永逸的：运营随时会加活动页，页面落进哪个分包、预载规则要不要跟着调，需要一条发布纪律来约束。商城的做法是"包结构变更走独立评审"：任何新页面登记时必须回答三个问题——归主包还是分包、所在分包的当前体积余量、是否需要新增预载规则；三个答案写进提交说明，评审通过才动 pages.json。这条纪律的收益在两个月后显现：主包体积曲线平稳、没有"随手塞进主包"的暗增长、预载规则与实际动线保持一致。结构性的文件配上结构性的纪律，包结构才能长期服役。

本节要点回顾

• 体积红线：主包与单分包各约两兆、总体约二十兆，static 大图是主包膨胀头号推手；
• 分包按用户动线切，一次任务的页面聚一包，边界别横在流程中间；
• preloadRule 跟页面配时机，主动线 all、重活动 wifi，规则要用弱网真机验证；
• H5 端分包是懒加载、App 端分包偏工程组织，验证策略按端分开；
• 骨架屏是分包未就位的兜底体验，白屏抢救从预载配置查起。

页面动线与包结构齐备，下一章为页面灌注数据：状态、存储、请求与长连接。