想象一下，你请了一家搬家公司来搬家。所有家具、衣物、厨具塞满了整整一卡车，可小区保安却拦下来说：“货车限载 2 吨，你这车货超了，进不了门。” 你只能把车停在门口，一件一件往里搬，全家人站在楼下干等。小程序的世界里也有类似的场景——你的代码包就是卡车，微信小程序对主包体积有硬性限制（约 2MB），一旦超限，不仅发布失败，用户打开时更是慢如蜗牛，等不到页面加载就滑走了。 聪明的做法是：把这辆大卡车拆成“必用”和“备用”两部分。日常必需的东西放主包，沙发、电视、床这些进门就要用的，先装车；不常用的东西放进分包，就像换季衣物、露营装备，等真要用时再送过来，甚至提前安排一辆小货车在楼下“预加载”待命。这就是小程序的分包加载与预加载策略：让首屏更快，让用户更快看到内容。

岗位关联

对 AI 从业者和前端工程师而言，理解分包与预加载，意味着你能从架构层面主导小程序的启动性能优化，用可量化的指标提升用户体验、留存率与商业化价值，这是移动端开发中最具含金量的基本功之一。

目录
  1. 可视化演示
  2. 超限困境
  3. 分包划分
  4. 分包配置
  5. 预加载策略
  6. 独立分包
  7. 按需加载
  8. 体积压缩
  9. 性能监测
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

超限困境

搬家公司的卡车在小区门口被保安拦住了——“限载 2 吨，你这车货超了。” 你回头看看塞满的家具，沙发必须带，电视必须带，可那台跑步机、整箱换季衣物，明明一年也用不上几回，却白白占着卡车的载重。小程序的世界里，这个“卡车”就是主包：微信规定小程序主包不超过 2MB，整包不超过 20MB。当你把所有页面、图片、组件全部塞进主包，体积一路飙升，用户点开小程序时，下载、解析、执行的时间被无限拉长，首屏转圈圈，用户等得不耐烦，直接退出——流量和留存双输。

启动耗时的本质是一个串行链路：先下载代码，再解析 JavaScript，最后执行渲染逻辑。每一项都随包体积线性增长。我们把这条链路写成公式：

回到搬家现场：如果卡车超载进不了门，再多的家电也白搭。同理，主包超限，小程序直接发布失败；即便勉强压线，用户也会在启动白屏中流失。所以，第一步不是谈优化技巧，而是认清“主包体积=启动体验的天花板”这个残酷事实。

Tlaunch=Tdownload+Tparse+Texecute\displaystyle T_{launch} = T_{download} + T_{parse} + T_{execute}
这个公式说明：启动耗时 = 下载时间 + 解析时间 + 执行时间，三者叠加。想缩短总时长，就得减少“必须一次性下载”的体积。
  1. 下载耗时代码包从服务器传输到用户手机的时间，体积越大越慢。
    Tdownload=VmainBnetworkT_{download} = \dfrac{V_{main}}{B_{network}}
  2. 解析耗时JavaScript 引擎读取并编译代码的时间，代码行数越多越慢。
    Tparse=k×NlinesT_{parse} = k \times N_{lines}
  3. 执行耗时运行初始化逻辑、渲染首屏的时间，依赖主包内的关键代码。
    Texecute=∑i=1mtinit_iT_{execute} = \sum_{i=1}^{m} t_{init\_i}

分包划分

既然卡车限载，那就把货拆成两车：一车是进门就要用的客厅家具，另一车是留着备用、需要时再送的房间杂物。 搬家前，你先给每个房间贴好标签：沙发、茶几、电视属于客厅（主包），跑步机、书籍、冬衣属于储物间（分包）。小程序的分包划分逻辑与此完全一致——按页面维度拆分。

划分的核心原则是“入口必需”与“低频延后”：tabBar 页面、首页、公共组件库、全局工具函数必须留在主包，它们是用户一进来就要看到的；而用户中心、订单详情、活动页、直播页等低频业务，统统划入分包。这样主包只保留最小骨架，体积大幅下降。

划分后要满足两条硬约束：主包体积不超限，同时所有分包的总体积加回主包等于整包体积。公式如下：

标签贴好了，房间分好了，但光有分类还不够——你得把这套分类告诉搬家公司，让他们照着执行。这就引出下一步：分包配置。

Vmain≤Vlimit,Vmain+∑i=1nVsub_i=Vtotal\displaystyle V_{main} \le V_{limit}, \quad V_{main} + \sum_{i=1}^{n} V_{sub\_i} = V_{total}
  1. 主包约束主包体积必须小于平台限制（微信约 2MB）。
    Vmain≤VlimitV_{main} \le V_{limit}
  2. 体积守恒拆分只是“挪位置”，不是“变魔术”，主包与各分包之和仍是整包体积。
    ∑i=1nVsub_i=Vtotal−Vmain\sum_{i=1}^{n} V_{sub\_i} = V_{total} - V_{main}
  3. 目标函数在约束内让主包尽量小，同时避免分包拆得太碎导致请求过多。
    min⁡Vmain,s.t.Nsub≤Nmax\min V_{main}, \quad \text{s.t.} \quad N_{sub} \le N_{max}

分包配置

你在搬家公司的登记表上写：“储藏室货箱，标签 A，送到后请放到储物间；客厅货箱，标签 B，直接搬进客厅。” 搬家公司一看标签就懂了。小程序的配置表同样一目了然，就是 app.json 里的 subpackages 字段（部分版本也叫 subPackages）。

每个分包需要声明两样东西：root 指明分包的根目录，pages 列出该分包下的所有页面路径。开发者工具会依据这份清单，在构建时把对应目录下的代码独立打包成一个子包。配置完成后，还需要了解两条重要规则：主包不能引用分包资源，不同分包之间也不能互相引用，否则会报错；想在分包内共享公共代码，必须把公共部分提取到主包。

配置逻辑可以抽象成一张“目录—包”的映射表：

登记表填好了，搬家公司的车按计划出发。但你在客厅整理沙发时突然想到：待会要去储物间拿书，与其干等，不如让搬家公司提前把书箱送到储物间门口——这就是预加载的朴素原型。

Pi={rooti,  pagesi},i=1,2,…,n\displaystyle P_i = \{ root_i, \; pages_i \}, \quad i = 1, 2, \dots, n
  1. 分包映射第 i 个分包由根目录加页面列表唯一确定。
    Pi={rooti,pagesi}P_i = \{ root_i, pages_i \}
  2. 页面归属任意页面至多属于一个包，保证加载路径唯一。
    ∀page∈Pages,∃!Pi∋page\forall page \in Pages, \quad \exists! P_i \ni page
  3. 引用约束分包只能访问主包和自己的资源，不能跨包引用。
    R(Pi)⊆M∪PiR(P_i) \subseteq M \cup P_i

预加载策略

搬家师傅是个聪明人，他看你正在客厅摆沙发，估摸着你半小时后会去书房，于是提前把书箱从卡车上卸下来，直接搬到书房门口。等你走进书房，书已经安安静静躺在那儿了。小程序里的 preloadRule 就是这位“有远见的师傅”：它允许你声明，当用户进入某个页面时，提前下载指定的分包资源。

配置方式很简单，在 app.json 中为某个页面路径配置 network 和 packages 两个字段。network 控制预加载的网络条件，默认 wifi，这意味着只有在 WiFi 环境下才会预加载，避免消耗用户流量；packages 指定要预加载的分包名称。预加载的本质是用空闲时间换等待时间：用户浏览当前页时，网络处于闲置状态，正好用来下载接下来大概率会访问的资源。

预加载要真正见效，必须满足一个时间不等式：预加载完成时刻，要早于用户真正进入分包页面的时刻。

预加载是“用今天的流量换明天的速度”，时机选得好，用户毫无感知；选得不好，白白消耗流量。而有一种更极致的策略，连“先进主包”都省了——独立分包。

Tpreload<Tneeded\displaystyle T_{preload} < T_{needed}
  1. 预加载完成时刻分包资源下载完毕的时间点，取决于网络速度和包体积。
    Tpreload=Ttrigger+VsubBT_{preload} = T_{trigger} + \dfrac{V_{sub}}{B}
  2. 用户需要时刻用户从当前页点击进入分包页面的时间点，由用户行为决定。
    Tneeded=Ttrigger+Tuser_behaviorT_{needed} = T_{trigger} + T_{user\_behavior}
  3. 提前量条件只要预加载完成得够快，用户点击时资源已就位，体验接近秒开。
    ΔT=Tneeded−Tpreload>0\Delta T = T_{needed} - T_{preload} > 0

独立分包

有些东西你根本不想放进客厅的储物清单里，比如车里的应急工具箱：不需要先回家拿钥匙、开客厅门，就能直接打开后备箱取用。独立分包就是这样一个“随车工具箱”：它不依赖主包即可独立运行，有自己的入口页面，用户通过特定路径可以直接进入独立分包，无需先下载主包。

典型场景是活动页、直播页、扫码落地页——用户从外部扫码进小程序，目标是明确的活动页面。普通分包必须等主包下载完才能启动，而独立分包直接从自身代码启动，省去了主包下载时间，冷启动明显更快。但要注意两点：独立分包无法访问主包资源，因此公共依赖要自带或尽量精简；不同平台（微信、支付宝、抖音）对独立分包的命名和限制略有差异，适配时需要查阅各平台文档。

独立分包的启动耗时可表示为：

工具箱虽好，但不能把整个家都搬进车里。独立分包只适合高频、入口明确、强隔离的场景。接下来，我们再看看另一类精细优化：按需加载。

Tlaunch_indep=Tbase+Tsub\displaystyle T_{launch\_indep} = T_{base} + T_{sub}
  1. 基础库启动小程序运行环境（如微信客户端内核）初始化耗时，与业务包体积无关。
    Tbase=CT_{base} = C
  2. 独立分包加载仅需下载并执行当前独立分包的代码。
    Tsub=VindepBnetwork+tparse_indepT_{sub} = \dfrac{V_{indep}}{B_{network}} + t_{parse\_indep}
  3. 对比普通分包普通分包要先加载主包再加载分包，独立分包省去主包下载项。
    Tlaunch_common=Tbase+Tmain+Tsub>Tlaunch_indepT_{launch\_common} = T_{base} + T_{main} + T_{sub} > T_{launch\_indep}

按需加载

搬家时你有没有这种经验？纸箱上写着“杂物，用时再拆”，可你总忍不住把十几个箱子全拆开翻找。聪明的做法是用到哪个拆哪个。小程序里的 require.async 就是那把“用到才拆的剪刀”：它允许代码在运行时异步加载某个分包中的模块，而不是启动时就全部加载。

具体来说，当用户触发某个操作（比如点击“查看订单”）时，再通过 require.async 动态引入对应分包里的模块。这样原本必须打进主包的代码，可以挪进分包，进一步缩小主包体积。配合分包异步化，还可以让子包中的组件、页面被异步引用，甚至在分包之间互相跳转而不额外等待。

按需加载的本质，是把“串行等待”变成“并行就绪”。同步加载必须等 A 和 B 依次完成，而异步加载可以让两者同时进行，感知耗时取最大值：

按需加载让代码“随叫随到”，减少首屏无用功。但别忘了，纸箱再精简，里面的东西本身也得瘦身——下一步，给资源“挤水分”。

Tsync=TA+TB,Tasync=max⁡(TA,TB)\displaystyle T_{sync} = T_A + T_B, \quad T_{async} = \max(T_A, T_B)
  1. 同步耗时按顺序加载两个模块，总耗时是两者之和。
    Tsync=TA+TBT_{sync} = T_A + T_B
  2. 异步耗时两个模块并行下载，总耗时是较慢者的耗时。
    Tasync=max⁡(TA,TB)T_{async} = \max(T_A, T_B)
  3. 收益空间当两个模块体积相近时，异步加载几乎节省一半时间。
    ΔT=min⁡(TA,TB)\Delta T = \min(T_A, T_B)

体积压缩

搬家老手都知道：被褥塞进真空压缩袋，能省一半空间；沙发脚能拆就拆，木板叠着放，车厢立刻宽敞许多。小程序代码同样如此。体积压缩不是改变功能，而是改变数据的“拥挤程度”。

常用的压缩手段有四类：图片压缩（把 PNG 转 WebP，裁剪不必要的分辨率）、代码压缩（去除空格、缩短变量名）、去重提取（公共组件和工具函数提取到主包，避免每个分包各存一份）、静态资源瘦身（删除未使用的图标和字体）。其中图片往往是体积大户，一张未经处理的 2MB 设计稿图片，压缩后可能只剩 200KB，效果立竿见影。

压缩率可以量化地表达为：

纸箱小了，搬运自然轻松。但优化做得好不好，不能靠感觉，得靠数据说话——搬完家的最后一步，是全面检查。

Vafter=Vbefore×(1−λ)\displaystyle V_{after} = V_{before} \times (1 - \lambda)
  1. 压缩率λ 表示缩减比例，图片压缩通常可达 0.5~0.9。
    λ=Vbefore−VafterVbefore\lambda = \dfrac{V_{before} - V_{after}}{V_{before}}
  2. 压缩后体积原始体积乘以剩余比例，得到压缩后的包体积。
    Vafter=Vbefore×(1−λ)V_{after} = V_{before} \times (1 - \lambda)
  3. 多手段叠加多种压缩手段的效果近似相乘，而非简单相加。
    Vfinal=Voriginal×∏j=1k(1−λj)V_{final} = V_{original} \times \prod_{j=1}^{k} (1 - \lambda_j)

性能监测

搬完家，你拿出检查清单：客厅灯亮不亮？水龙头漏水吗？储物间的东西到底有多少是三年没碰过的？没有复盘，就没有优化。 小程序上线后同样需要一套性能监测体系，持续跟踪启动耗时和包体积的变化。

具体做法是在 App 的 onLaunch 中记录启动时间戳，在首屏 onReady 中计算差值；添加性能监控面板聚合启动耗时、分包加载耗时等指标；配合平台提供的体验评分工具，在每次代码提交后对比包体积变化。更进阶的做法是灰度发布：先让 5% 的用户体验优化后的版本，验证启动耗时下降和新版本无回归，再逐步放量到全量用户。

优化的收益，用相对变化率来衡量最直观：

从超限困境到监测复盘，整个流程就像一个完整的搬家工程：认清限制、合理划分、精细配置、预判需求、独立应急、按需拆装、压缩减负、持续复盘。每一步都踩在“让用户更快看到内容”这条主线上。

R=Tbefore−TafterTbefore×100%\displaystyle R = \dfrac{T_{before} - T_{after}}{T_{before}} \times 100\%
  1. 优化前基准记录优化前的启动耗时作为基准线。
    TbeforeT_{before}
  2. 优化后实测上线后统计的真实启动耗时，需在相同网络环境下对比。
    TafterT_{after}
  3. 下降幅度差值占基准值的百分比，反映优化效果的显著程度。
    R=Tbefore−TafterTbefore×100%R = \dfrac{T_{before} - T_{after}}{T_{before}} \times 100\%

AI 应用场景

场景一：电商小程序大促页秒开

阶段：性能优化与用户行为预测

解决的问题：大促期间流量井喷，用户从分享卡片进入活动页，传统做法要先下载完整个主包才能渲染活动页，导致大量用户在高并发下流失。AI 结合用户点击行为预测，将活动页设为独立分包或配置预加载规则，让用户进入时资源已就绪。

具体案例：某电商小程序把“限时秒杀页”配置为 preloadRule 的预加载对象，当用户从首页进入商品详情时，后台提前下载秒杀分包；同时利用 AI 对用户历史行为建模，预测其下一步最可能访问的活动页，动态调整预加载的 package 列表。优化后首屏耗时从 3.2 秒降至 0.9 秒，大促当日转化率提升 22%。

场景二：多端小程序统一分包策略

阶段：跨平台配置生成与合规检查

解决的问题：同一产品要发布到微信、支付宝、抖音三个平台，各平台对主包体积、独立分包命名、预加载网络条件的限制各不相同，人工维护三套配置极易出错。AI 基于各平台规则库，自动生成对应的 app.json 分包配置，并检查是否超限。

具体案例：金融类小程序通过 AI 配置引擎，输入统一的页面目录树和业务优先级，自动输出三端分包方案：微信端用独立分包承载理财计算器，支付宝端用预加载缓存“我的账单”，抖音端因限制较严将直播组件异步化。上线后各端均无超限告警，启动耗时平均下降 35%。

Python 演示

python57 行
class SubpackagePlan:    def __init__(self, name, main_mb, speed_mbps):        self.name = name        self.main_mb = main_mb        self.speed_mbps = speed_mbps        self.subpackage_list = []        self.preload_map = {}     def add_subpackage(self, root, size_mb, independent=False):        self.subpackage_list.append({            "root": root,            "size_mb": size_mb,            "independent": independent        })     def set_preload(self, from_page, target_root):        self.preload_map[from_page] = target_root     def download_ms(self, size_mb):        return size_mb * 8000.0 / self.speed_mbps     def cold_start_ms(self):        return self.download_ms(self.main_mb) + 300     def enter_subpackage_ms(self, root):        pkg = None        for item in self.subpackage_list:            if item["root"] == root:                pkg = item        if pkg is None:            return None        if root in self.preload_map.values():            return 0        if pkg["independent"]:            return self.download_ms(pkg["size_mb"]) + 150        return self.cold_start_ms() + self.download_ms(pkg["size_mb"])     def report(self):        total_mb = self.main_mb + sum(i["size_mb"] for i in self.subpackage_list)        print("方案:", self.name)        print("主包: %.2fMB, 分包数: %d, 整包: %.2fMB" % (            self.main_mb, len(self.subpackage_list), total_mb))        print("冷启动耗时(10Mbps): %.0fms" % self.cold_start_ms())        for item in self.subpackage_list:            cost = self.enter_subpackage_ms(item["root"])            print("进入 %s: %dms" % (item["root"], cost)) def main():    plan = SubpackagePlan("分电商小程序", 1.2, 10)    plan.add_subpackage("pages/market", 0.8)    plan.add_subpackage("pages/live", 1.5, independent=True)    plan.add_subpackage("pages/user", 0.5)    plan.set_preload("pages/home", "pages/market")    plan.report() if __name__ == "__main__":    main()
目的：模拟一个电商小程序的分包方案，计算主包冷启动耗时、进入各分包页面的耗时，并展示预加载与独立分包对耗时的影响。
  1. self.main_mb主包体积，代表“客厅必需家具”，是小程序启动时必须下载的部分。
  2. plan.add_subpackage("pages/live", 1.5, independent=True)添加独立分包，模拟“随车工具箱”，无需先加载主包。
  3. plan.set_preload("pages/home", "pages/market")声明预加载规则：用户进入首页时提前下载活动分包。
  4. download_ms根据体积和网速估算下载耗时，公式为体积(MB)×8000÷网速(Mbps)。
  5. cold_start_ms冷启动 = 主包下载耗时 + 300ms 解析执行常量。
  6. enter_subpackage_ms计算进入不同分包的成本：预加载命中的返回 0，独立分包只需自身下载，普通分包要先走冷启动。
  7. report汇总打印整包体积与各分包访问耗时，直观对比优化效果。

常见误区

误区反正分包能减负，干脆把能拆的代码全拆进分包，主包留个空壳，启动一定最快。

正解主包确实要小，但不能“空”。首页、tabBar 页面、公共组件、全局状态管理这些“进门就要用”的资源必须留在主包。如果首页引用的组件被拆进分包，启动反而要多一次分包下载请求，首屏更慢。主包和分包的关系是“骨架与血肉”：骨架要精简但不能缺失。

为何常见：只看到“主包小=启动快”的表面关系，忽略了页面依赖关系和额外请求开销。

误区拆得越细，按需加载就越精准，所以把每个页面都单独设一个分包。

正解分包并不是免费午餐。每个分包都会产生独立的下载请求、解析上下文和内存开销。如果拆成几十个小包，请求暴增、缓存命中率下降，反而拖慢性能。一般建议按业务模块划分，3-8 个分包为宜，兼顾粒度与开销。

为何常见：把“按需加载”理解成了“极致拆分”，忽略了请求数量与包大小的平衡。

误区预加载提前下载资源，用户如果没点进去就白下载了，纯属浪费流量。

正解preloadRule 默认只在 WiFi 网络下触发，且通常会限制预加载分包的体积上限。用极少量的流量成本，换取用户点击时的秒开体验，对留存和转化而言收益远大于代价。关键是选对“预判页面”：用数据统计用户下一步的高概率行为，而不是盲目全量预载。

为何常见：只算流量账，不算体验账和转化账，忽略了 WiFi 场景下的流量成本几乎为零。

误区独立分包也是分包，只是配置上多写一个字段，性能提升有限。

正解独立分包的本质区别在于不依赖主包即可启动。普通分包必须先等主包下载完才能运行，而独立分包直接拉起自身代码。它适合扫码、分享、推送直达的强入口场景，能砍掉主包下载时间，但代价是无法访问主包资源，公共依赖得自带，使用场景有明确边界。

为何常见：只看到名字相似，没有理解“启动链路”的差异，把配置语法和运行机制混为一谈。

面试题

Q1. 微信小程序主包体积的硬性上限约为多少？

单选题 · easy

  • A.1MB
  • B.2MB← 正确答案
  • C.5MB
  • D.10MB

答案：B。微信小程序主包上限约 2MB（整包约 20MB）。主包超限会导致上传报错。选项 B 正确，其他选项要么低估要么高估了平台限制。

Q2. 小程序中声明分包使用的配置字段是？

单选题 · easy

  • A.packages
  • B.modules
  • C.subpackages← 正确答案
  • D.chunks

答案：C。app.json 中通过 subpackages（也兼容 subPackages）声明分包，内部分别配置 root 和 pages。选 C。

Q3. 关于独立分包，下列说法正确的是？

单选题 · easy

  • A.必须依赖主包才能启动
  • B.不依赖主包，可独立运行← 正确答案
  • C.体积不受任何限制
  • D.只能由主包跳转进入

答案：B。独立分包的核心特点是可以不加载主包而独立启动，适合扫码等入口直达场景。但它体积有限制、不能访问主包资源，A、C、D 均错误。

Q4. preloadRule 中 network 字段的默认配置是？

单选题 · mid

  • A.all
  • B.3g
  • C.wifi← 正确答案
  • D.5g

答案：C。为防止消耗用户移动流量，network 默认值为 wifi，即只在 WiFi 环境下预加载分包，选 C。

Q5. 小程序分包异步化中，按需引入分包模块使用的 API 是？

单选题 · mid

  • A.require.async← 正确答案
  • B.Promise.all
  • C.importSync
  • D.loadModule

答案：A。require.async 用于运行时异步加载分包模块，将同步依赖变成按需加载，是分包异步化的核心 API，选 A。

Q6. 下列哪些资源应放置在主包中？

多选题 · mid

  • A.公共组件库← 正确答案
  • B.首页核心代码← 正确答案
  • C.全部营销图片
  • D.tabBar 页面← 正确答案

答案：ABD。主包应放“进门必需”资源：公共组件、首页代码、tabBar 页面。营销图片属于低频资源，可分到对应的活动分包中按需加载，C 错误。

Q7. 关于 preloadRule 配置，以下哪些描述正确？

多选题 · mid

  • A.可以指定预加载多个分包← 正确答案
  • B.可以设置网络条件← 正确答案
  • C.只能预加载主包
  • D.预加载不消耗流量

答案：AB。preloadRule 中 packages 可列出多个要预加载的分包，network 可设置 wifi 或 all，因此 A、B 正确。它预加载的是分包而非主包，且会消耗流量，C、D 错误。

Q8. 小程序单个分包的体积限制约为？

单选题 · hard

  • A.2MB← 正确答案
  • B.4MB
  • C.10MB
  • D.20MB

答案：A。微信小程序单个分包体积上限约 2MB，与主包一致；全部小程序包总计约 20MB。选 A，其他选项为主包或整包上限容易混淆。

Q9. 以下哪些做法能有效降低小程序启动耗时？

多选题 · hard

  • A.把公共代码重复放进每个分包
  • B.首页使用分包异步加载所有组件
  • C.将低频页面划入独立分包← 正确答案
  • D.图片压缩并转为 WebP 格式← 正确答案

答案：CD。低频页面用独立分包可跳过主包加载，图片压缩直接减小包体积，均能降低启动耗时。A 会增加体积，B 把首页组件异步化反而拖慢首屏，均错误。

Q10. 用户停留在首页阅读内容时，此时触发预加载分包的最优场景是？

单选题 · extreme

  • A.刚进入小程序立即预加载全部包
  • B.用户点击分包页面瞬间才加载
  • C.用户进入首页且网络空闲时预加载← 正确答案
  • D.用户退出小程序时预加载

答案：C。预加载的黄金时机是用户停留在当前页、网络空闲时，提前把下一个高概率页面所需的包下载好。A 会浪费流量且阻塞启动，B 失去了预加载意义，D 为时已晚。选 C。