分包小程序实战指南，轻松提升加载速度

打开微信，点开一个小程序，转圈圈转了三秒还没出来。你退出去，再也没回来。这不是用户没耐心，是开发者把家底全堆在门口了。小程序首次加载要下载整个包体，代码、图片、样式全塞一起，网络差一点就直接劝退。分包这技术，就是帮你把家当分门别类放好，用户进门只拿钥匙，不搬沙发。

分包的核心逻辑特别朴素：把小程序拆成主包和分包，主包只管启动必需的东西，其他页面扔进分包里。用户点进哪个功能，才去加载那一块。微信官方规定主包不能超过1.5MB，整个小程序不能超过20MB，但很多新手压根没意识到，自己辛辛苦苦写的页面，大部分用户根本不会点开。一个电商小程序，用户可能只看首页和商品详情，你非把售后政策、用户协议、店铺入驻这些页面全部塞进主包里，首屏加载能不慢吗？

我见过一个真实案例，某餐饮小程序，主包里有十几个页面，其实用户日常就点菜单和下单。老板不懂技术，开发图省事，所有页面平铺在一个包里。结果就是，每次启动都要下载几百KB甚至1MB的代码，在4G网络下还能忍，到了地铁里直接卡成PPT。后来把菜单、下单、订单列表拆成分包，主包只剩首页和登录逻辑，启动时间从3秒干到1秒内。用户没变，网络没变，就是包体结构变了，体验天差地别。

分包实操的第一步，是理清楚哪些东西必须留在主包。App.js、App.json、全局样式、首页、登录页，这些是启动就要用的，必须留在主包。剩下的页面，按业务模块归类。比如一个社区类小程序，帖子列表是一个分包，发布帖子是一个分包，个人中心是一个分包，每个分包独立成一个文件夹。微信的构建工具会自动识别subpackages字段，你只需要在app.json里配置好路径映射。

配置方式很简单，在app.json里加一个subpackages数组，每个元素包含root和pages。root是分包根目录，pages是分包内的页面路径。注意，分包里的页面路径不能跟主包重复，分包之间的页面路径也不能重复，否则微信会直接报错。还有一个容易踩的坑，分包里的资源文件，比如图片、字体，路径要写绝对路径，从项目根目录开始写，不要用相对路径，不然构建完资源找不到，页面白屏。

除了页面分包，还有个独立分包的概念，很多人没搞懂。独立分包比普通分包更狠，它不依赖主包，可以单独运行。适合什么场景？比如一个工具类小程序，用户可能直接通过分享卡片进入某个工具页面，根本不会先经过首页。这时候把工具页面做成独立分包，用户点分享卡片，直接加载这个分包的代码，连主包都不用下载。独立分包的配置跟普通分包一样，只是加了一个independent字段设为true。

但独立分包有个限制，它不能引用主包里的任何文件，包括公共组件、公共js、图片资源，都得在分包内部自己放一份。这就带来一个资源冗余的问题。我建议，除非某个页面确实需要被单独分享出去当入口，否则不要轻易用独立分包。普通分包已经能解决90%的加载问题，独立分包是给极端场景准备的。

分包之后的加载策略，也有讲究。微信的加载机制是，主包先加载完，然后按需加载分包。但如果你在分包页面里跳转到另一个分包页面，这两个分包之间的切换，会有一次额外的加载等待。为了避免这种体验，你可以用preloadRule做预下载。比如用户进入首页后，大概率会点进商品列表，你就在首页的preloadRule里配置预下载商品列表所在的分包。这样用户点进去的时候，分包可能已经下好了，秒开。

预下载的配置也很简单，在app.json里加一个preloadRule对象，key是触发预下载的页面路径，value是一个对象，包含network和packages字段。network指定在什么网络下预下载，比如all就是所有网络都预下载，wifi就是只在WiFi下预下载。packages是一个数组，填你要预下载的分包root路径。这里有个策略建议，预下载别贪多，只预下载用户最可能去的下一个分包，三个以上就会浪费流量，还可能拖慢主包启动。

还有一个细节，很多人分包后忘了处理tabBar。tabBar页面必须在主包里，不能放进分包。如果你把tabBar页面扔进分包，微信会直接报错，跑都跑不起来。所以，如果你的小程序底部导航有四个tab，这四页就必须全部留在主包，其他页面才能分包。这个限制很多人不知道，等到打包报错了才回头找问题，白白浪费半天时间。

分包后的体积优化，也别闲着。每个分包里可能有重复的公共代码，微信提供了分包异步化能力，可以让分包引用主包和其他分包里的组件和js。用require.async或自定义组件的方式，把公共逻辑抽出来放主包，分包里按需引用。这样分包体积还能再缩一圈。但注意，分包异步化只在微信基础库2.11.2以上支持，低版本用户会白屏，你要做好兼容判断。

回到开头那个场景，用户点开小程序，1秒内看到首页内容，这靠的不是服务器带宽，也不是代码优化，就是包体结构的合理拆分。分包不是新功能，微信从2017年就支持了，但直到现在，还有大量开发者没用好这个基础能力。我们做小程序，总想着加功能、调样式，却忽略了最基础的第一步——让用户能快速打开。

分包这件事，不是给大厂准备的，哪怕你只有三个页面，也有分包的余地。把启动必需的东西和其他功能拆开，用户进门的路径就短一截。这一截，就是留存率的差距。下次改版的时候，打开你的开发者工具，看看主包体积占了多少，是不是有页面从来没被点过，却一直躺在主包里拖慢启动速度。动手拆一下，10分钟的事，换来的是用户多等你一秒。