跳到主要内容

微信小程序分包怎么做？为什么要分包？有哪些坑？

本文默认语境是 uni-app 项目发布到微信小程序端。面试时要先强调：uni-app 只是开发框架，真正的包体限制、分包规则、启动加载行为，最终受 微信小程序平台 约束。

面试速答（30 秒版 TL;DR）​

  • 微信小程序分包的核心目的，是把不是首屏必须的代码和资源拆到子包里，减少主包体积和启动压力。
  • 平台上最硬的边界，面试里至少要先答出来：
    • 主包通常不超过 2M
    • 单个分包通常不超过 2M
    • 总包限制要注意资料版本差异，旧资料常见 20M，新资料里也能看到普通小程序 30M 的说法
  • 一句话理解：
    • 主包 放启动必需内容
    • 分包 放低频页面或独立业务模块
  • 面试里最重要的不是背配置项，而是说清楚：
    1. 为什么要分包
    2. 什么应该进主包，什么应该进分包
    3. 分包后页面跳转和公共依赖怎么设计
  • 如果项目是 uni-app，通常会在 pages.json 里配置 subPackages 或等价分包配置，然后由构建工具输出为微信小程序分包结构。

心智模型：分包本质是“启动路径优化”​

很多人会把分包理解成“代码组织方式”。

这不算错，但不够本质。

更准确地说，分包优化的是：

  • 小程序冷启动时到底要先下载和解析哪些资源

如果所有页面和依赖都在主包里，会出现两个问题：

  • 不常用页面也跟着首屏一起下载
  • 主包越来越大，启动越来越慢

所以分包的核心思想是：

  • 先让用户进来
  • 再按访问路径加载后续业务

1. 为什么微信小程序项目几乎都会聊分包​

因为小程序天然有包体约束，而且体验上很依赖启动速度。

实际项目里，包体膨胀通常来自这些地方：

  • 页面数量增多
  • 多业务线塞进同一个小程序
  • 大量静态资源
  • 公共组件和第三方库越来越多

如果不做分包，工程上很容易演变成：

  • 首页明明只要一小部分代码
  • 结果整个项目的大量低频页面都跟着启动链路一起进来

所以面试里可以直接说：

  • 分包本质是在做启动链路瘦身。

2. 先把平台限制背清楚：整个包、主包、分包各有多大​

这部分非常适合面试官追问：

  • 你说有包体限制，那具体是多少？
  • 主包和分包是不是一个限制？
  • 独立分包算不算在总量里？

如果你只会说“微信小程序有限制”，但说不出量级，回答会显得偏空。

2.1 面试里最稳妥的回答​

维度建议回答说明
主包通常不超过 2M首次启动必须下载，所以这是最该优先压缩的部分
单个普通分包通常不超过 2M首次进入对应业务模块时按需下载
整个小程序所有包总量要强调版本/主体类型差异旧资料常见 20M；近年的部分资料会写普通小程序 30M、服务商代开发小程序 20M
独立分包工程上也应按单包 2M 量级控制它解决的是“可独立启动”和隔离加载，不代表可以无限膨胀

2.2 为什么这里一定要写“版本差异”​

微信小程序的包体限制，社区里最容易出现两类资料混用：

  • 一类是很多年都在流传的：总包 20M，主包 2M，单个分包 2M
  • 另一类是较新的资料：普通小程序总包 30M，服务商代开发小程序总包 20M，单个主包/分包 2M

所以更成熟、更不容易答错的说法是：

  • 主包和单个分包按 2M 控制，这是最稳定的工程约束
  • 总包上限要以当期微信开放文档和开发者工具/上传后台的实际校验为准

2.3 面试推荐答法​

你可以直接这样说：

微信小程序分包除了讲“为什么拆”，还要讲平台约束。通常主包要控制在 2M 内，单个分包也通常是 2M 级别；总包限制在不同版本资料里有 20M 和 30M 的差异，我会以微信开放文档当前版本和发布校验结果为准。工程实践里，先把主包压小、再控制每个业务分包不要失控，这是最关键的。

2.4 工程上的落地建议​

  • 不要等到发版时才看包体，最好每次发版前都检查主包和各分包产物大小
  • 如果首页不需要某些大图、图标集、富文本模板，不要放进主包
  • 某个业务模块专用的组件、工具函数、静态资源，尽量跟着分包走
  • 独立分包虽然能降低主包依赖，但它的资源边界更严格，不要把它当成“额外仓库”

3. 什么应该放主包，什么应该放分包​

这是面试高频追问，答不好就会显得只会背概念。

3.1 主包放什么​

主包应该只放：

  • 启动页
  • 常驻 Tab 页
  • 首屏必须的公共代码
  • 全局样式、基础运行时、少量公共组件

判断标准很简单：

  • 用户一进来不加载它，页面就起不来

3.2 分包放什么​

分包更适合放：

  • 订单模块
  • 会员中心
  • 营销活动页
  • IM、客服、帮助中心
  • 低频运营专题

判断标准是：

  • 用户不是每次都会访问
  • 模块相对独立
  • 页面和依赖可以局部闭合

3.3 一个常见误区​

很多人会把“公共组件很多”理解成“都应该放主包”。

这不一定对。

更合理的判断是：

  • 高频公共依赖 才值得进主包
  • 只被某个业务模块使用的公共代码，更适合跟着该分包走

否则“公共化”会反过来把主包越做越胖。

4. uni-app 里分包通常怎么配置​

在 uni-app 里，一般会在 pages.json 里声明页面和分包信息。

示意配置：

{
  "pages": [
    {
      "path": "pages/home/index",
      "style": {
        "navigationBarTitleText": "首页"
      }
    }
  ],
  "subPackages": [
    {
      "root": "pages-order",
      "pages": [
        {
          "path": "list/index",
          "style": {
            "navigationBarTitleText": "订单列表"
          }
        },
        {
          "path": "detail/index",
          "style": {
            "navigationBarTitleText": "订单详情"
          }
        }
      ]
    },
    {
      "root": "pages-member",
      "pages": [
        {
          "path": "center/index",
          "style": {
            "navigationBarTitleText": "会员中心"
          }
        }
      ]
    }
  ]
}

这个配置本身不难，难的是分包边界怎么切。

面试里真正加分的是你能继续往下说：

  • 订单相关页面尽量放一个分包内，减少跨包跳转带来的维护复杂度
  • 某个分包的组件、静态资源、局部逻辑尽量跟包走，避免主包被公共依赖反向拖大

5. 分包之后，加载链路发生了什么变化​

分包前：

  • 用户一进小程序，就要承担更多页面代码和资源的下载解析成本

分包后：

  • 用户先加载主包并进入首页
  • 只有跳到订单、会员、活动等模块时，才按需拉对应分包

这意味着收益主要体现在：

5.1 冷启动更轻​

  • 主包更小
  • 启动下载和解析压力更低

5.2 低频业务不阻塞首屏​

  • 用户没进入订单页，就没必要先拿订单模块代码

5.3 模块边界更清晰​

  • 便于按业务拆分页面、组件、资源

不过也要补边界：

  • 分包优化的是启动与按需加载，不是把所有性能问题都解决。

如果页面本身渲染很重、接口很慢，分包也救不了运行时卡顿。

6. 工程上怎么划分分包更合理​

6.1 按业务域拆，而不是按“页面数量平均分”​

更推荐这样拆：

  • 首页 / Tab 主链路放主包
  • 订单一组
  • 会员一组
  • 活动一组
  • 设置 / 帮助一组

原因是：

  • 业务边界清晰
  • 依赖更容易收口
  • 后期迭代更稳定

6.2 让分包内部尽量自洽​

如果一个分包经常强依赖主包里大量业务组件，就会出现两个问题：

  • 主包被迫越来越大
  • 分包名义上拆开了，实际上还是高度耦合

所以分包设计时要尽量做到：

  • 页面
  • 组件
  • 静态资源
  • 局部工具函数

都优先在包内闭环。

6.3 不要为了分包而分包​

如果项目本来页面很少、主包也不大，硬拆分包可能只会增加：

  • 配置复杂度
  • 维护成本
  • 跨包引用问题

所以面试里可以说得更成熟一些：

  • 分包不是教条，而是当项目体量和启动压力上来后的一种结构化优化手段。

7. 典型题 & 标准答法​

Q1：微信小程序为什么要分包？​

标准答法：

  • 因为小程序有包体限制，而且启动性能很敏感。分包可以把非首屏、低频访问的业务模块拆出去，只保留首页和高频公共能力在主包里，从而降低冷启动下载和解析压力。

Q2：主包和分包分别应该放什么？​

  • 主包放启动必需页面和高频公共依赖
  • 分包放低频、相对独立的业务模块
  • 判断标准不是“这个模块大不大”，而是“首屏是不是必须要它”

Q3：分包后是不是越多越好？​

  • 不是。
  • 拆得过细会增加维护复杂度，也可能造成跨包依赖混乱。
  • 更合理的方式是按业务域做中等粒度拆分。

Q4：微信小程序分包的大小限制怎么答？​

  • 最稳妥的回答是：
  • 主包通常按 2M 控制
  • 单个分包通常也按 2M 控制
  • 总包限制要明确说明有版本差异，旧资料常见 20M，新资料里也能看到普通小程序 30M 的说法
  • 真正落地时，以微信开放文档当前规则和发布校验结果为准

8. 常见追问​

8.1 分包和路由懒加载是一个东西吗？​

不是一个层次。

  • 路由懒加载更常见于 Web SPA，把某个页面组件拆成异步 chunk
  • 小程序分包是平台层面的包结构划分

它们都在做“按需加载”，但运行环境和约束不同。

8.2 分包后公共依赖怎么处理？​

要看依赖的真实使用范围：

  • 如果首页和多个主链路都依赖，才考虑放主包
  • 如果只在某个业务模块使用，更适合跟分包走

关键原则是：

  • 谁高频、谁首屏必须，谁优先留在主包。

8.3 分包后跳转会不会更慢？​

首次进入某个分包页面时，可能会有一次分包下载成本。

但整体体验通常更优，因为：

  • 不是所有用户都要为所有低频业务提前买单

所以这是典型的：

  • 用局部延迟换整体启动收益

8.4 独立分包是不是可以绕开主包限制？​

不是。

  • 独立分包的价值在于它可以不依赖主包独立启动某些业务入口
  • 但它不是“无限容量扩展包”
  • 真正的工程重点仍然是控制单包体积、减少无效依赖、遵守平台当前校验规则

9. 易错点 / 坑​

  • 把很多低频业务公共代码提到主包，导致主包重新膨胀
  • 按页面个数平均拆包，没有按业务边界拆
  • 分包后仍然让首页强依赖分包里的组件或资源
  • 只背“总包 20M”或者只背“总包 30M”，却不说明资料版本差异
  • 只关注包体，不关注页面首屏接口和渲染性能
  • 以为分包能代替代码优化、图片优化、接口优化

速记要点​

  • 分包 = 把低频业务延后加载
  • 主包和单个分包，面试里先按 2M 讲最稳
  • 主包只放启动必需内容
  • 总包限制要注意旧资料 20M 与新资料 30M 的版本差异
  • 分包按业务域拆，不按页数平均拆
  • 分包优化的是冷启动链路
  • uni-app 里通常在 pages.json 配分包
  • 分包不是越细越好，关键是边界和依赖收口