2026年了，Uni-app 小程序的图都塞在 static 里，提审前才发现主包超限，这坑能提前躲开吗？

一、先说结论：主包超限多半不是业务代码写多了

按 2026 年的项目交付经验，Uni-app 打小程序提示主包超限时，多数情况下的根因不是业务逻辑写得多，而是静态资源没搬走、三方依赖整包引入，或者所有页面都挂在主包上。先量体积分布，再决定删依赖还是拆分包：超出平台上限比较少的那一档，靠挪资源、改按需引入、换压缩方式通常就能过；超出量接近上限的一半甚至更多，才需要动分包结构。按经验区间，光收拾资源和依赖这一层，常见能压下来几十 KB 到几百 KB，具体取决于项目里塞了多少图。

从常见项目看，一个中等规模的小程序，业务 JS 在主包里往往只占一小块，真正吃体积的是大图、字体、视频封面这类静态资源，以及被整包引入却只用了其中一两个功能的依赖。所以第一步不是删代码，而是量。

二、同一个 Uni-app 项目，为什么 H5 不卡、小程序先卡

小程序和 H5 的加载模型不一样：H5 是边下载边渲染，体积大一点，用户的体感是慢；小程序要先把包下载到本地再启动，主包越大，首次打开前的等待越长，弱网和低端安卓机上差距会被放大。同一套代码，H5 端一直没出事，小程序端却先卡在提审环节，多半就是这个原因。

更硬的一层是平台规则：按微信小程序官方文档，主包体积常见上限在 2MB 左右，所有分包合计的常见上限在 20MB 上下，具体数值以各平台最新规范为准，交付前建议照官方文档再核对一次。超限不是体验差一点，而是包传不上去、提审过不去，属于卡流程的问题，不是纯优化问题。

• 首次打开等待：主包越大，新用户第一次进来等得越久，跳出越明显。
• 提审通过：超过上限直接无法上传，发布周期会被顶回来。
• 低端机启动：同样体积，低端机上体感差距更大。

三、删依赖还是拆分包：一组可核对的对比

这两条路不是二选一，而是先后问题。下面按项目里常见的收益与工期区间做个对比，数值随项目规模浮动，只能当参照，不建议照搬。

1. 挪静态资源到 CDN：主包收益常见几十 KB 到几百 KB，工期常见半天到 1 个工作日；代价是要重新核验弱网首屏和图片引用方式，运行时拼路径的图容易漏。
2. 依赖改按需引入：收益常见几十 KB 到一两百 KB，工期常见 0.5 到 1 个工作日；代价是部分库按需配置后接口有差异，要回归相关页面。
3. 普通分包拆分：主包收益常见几百 KB 甚至更多，工期常见 1 到 3 个工作日；代价是跳转路径、tabBar 配置、公共组件归属都要跟着改，返工成本高于前两项。
4. 独立分包与分包异步化：收益看场景，工期常见 2 到 5 个工作日；代价是公共库可能重复打包，总包不一定更小，配置也更绕。

判断口径可以简单记：能用低风险手段解决，就别急着动路由结构。动结构会牵动跳转与分包配置，一旦改错，排查成本远高于挪几张图。

四、真正吃掉主包的三块，按顺序收拾

4.1 静态资源：先搬，别先删

大图、字体、音频、视频封面这类文件，优先挪到 CDN 或按需从分包加载。注意别只改本地目录就以为完事——运行时拼接出来的图片路径常常无法被正确拆分，先确认引用方式再挪，否则本地看着小了，正式包里还在。

4.2 依赖：整包引入是常见的大头

UI 库、图表库、工具库整包引入时，用不到的模块也会进包。2026 年多数主流库都提供按需引入或分包导出，改配置通常比拆页面省事。要留意按需之后接口可能略有差异，改完把相关页面回归一遍。

4.3 页面：按访问频次分，而不是按文件夹整齐分

tabBar 页面、启动页和分级入口页要留在主包，这部分体积拆不掉。其余低频页、活动页、扫码落地页可以进分包。判别方法就一条：用户会不会从首页一路点进去？会，就留在主包；靠扫码或分享直达，再考虑独立分包。

五、哪些体积是拆不掉的，别把希望全押在分包上

tabBar 页、启动页、公共组件和被多个分包共用的库，通常都要留在主包或主包可见的位置。独立分包虽然能独立运行，但不能依赖主包资源，公共库得重复打包，常见结果是主包小了、分包大了，整体包不一定更省。拿不准的时候，先按「主包留一成左右余量」设预算，而不是贴着上限跑，否则一次活动页加两张图就又超了。

还有一条容易被忽略的：提审看的是正式包，和开发时看到的本地产物统计口径不一定一样，调试代码、映射文件都可能混进去。所以量体积要量正式包，别拿开发版的数据下结论。

六、交付现场：一次提审返工是怎么发生的

项目里常见的是这种约束：周期压得紧，运营要求首页轮播和首屏活动图必须是高清大图，素材由甲方临时给，压缩来不及做。当时的做法是先把图直接丢进 static 目录省事，本地跑起来一切正常，等到要提审才发现主包超限，包传不上去。代价是临时把图转到 CDN、重做图片引用方式，再走一遍真机验证，整体多花了大约 1 到 2 个工作日，活动上线时间也跟着往后挪。

按 2026 年的交付经验区间，这类「资源没搬走」导致的返工，常见占掉半天到两天；如果牵连到分包结构，常见要 1 到 3 个工作日。所以交付前会先核对三件事：静态资源放没放对位置、引用方式能不能被正确拆分、主包余量还剩多少。这三件事花的时间不多，但能省下一次提审返工。

七、适用与不适用边界

拆分包不是所有 Uni-app 项目的必选项。判断标准可以压成一句话：主包是否已经贴近平台上限，以及是否存在明确的低频页面或大体积资源。两条都不成立，硬拆只会让路由和跳转更容易出错。

• 适合拆：多页面电商、内容站、活动运营频繁，或需要同时出小程序和 App、H5 的项目；页面数量多、静态资源大、主包已经贴近上限。
• 不必拆：单页工具、页面数量个位数、依赖很少的轻量小程序；一两个人维护时，拆包带来的路径复杂度可能超过收益。
• 拿不准时：如果同时还要发 App 和 H5，拆包策略以体感更差的那一端为准，通常是小程序端。

常见问题

Uni-app 主包超限，先删依赖还是先拆分包？

先看量出来的占比。依赖和静态资源占大头，就先挪资源、改按需引入；业务页面占大头，再考虑分包。顺序反了容易白改一轮。

图片放 static 目录和放 CDN，对主包影响差多少？

大图、字体这类文件挪到 CDN，主包常见能降几十 KB 到几百 KB，代价是多一次网络请求，弱网首屏可能变慢，要按页面重要程度权衡。

独立分包就比普通分包更省体积吗？

不一定。独立分包不能共用主包资源，公共库需要重复打包，常见结果是主包小了、分包变大，总包未必更省，要按整体算。

本地真机跑没问题，提审还是提示超限，常见原因是什么？

常见原因是开发版和正式包统计口径不同，或有调试代码、多余映射文件混进包里。提审前用工具重新量一次正式包的体积分布。

多个分包都要用的组件，该放主包还是放分包？

只有一个分包用就放该分包；多个分包共用，可放主包或单独建公共分包。放主包会撑主包体积，按占用大小和调用频次权衡。

如果这个月就要提审，建议先把主包体积量一遍：靠资源压缩和按需引入能解决，就别急着动路由结构；页面确实多、资源确实大，再按访问频次拆分包。需要提醒的是，轻量小程序或单人维护的项目拆包收益有限，优先把资源压下来通常更划算。