小程序按需注入教程｜懒加载启动提速与兼容回归 – MPForge
直接回答：这是写给小程序开发的按需注入与懒加载教程：小程序启动时默认把所有代码注入一遍，页面一多启动就慢。开启按需注入（lazyCodeLoading）后只注入当前页面需要的代码，启动耗时可明显下降。但它改变的是全局注入行为，全量开启前必须过兼容回归。本教程给出一套「评估、开启、压测、灰度、可回滚」的稳妥口径。MPForge（DEVDIY 旗下）交付时按这套流程走，避免提速变成事故。
一、为什么启动慢：默认注入的代价
结论句：页面数越多，默认全量注入浪费的启动时间越多，这就是按需注入要省下来的部分。
小程序启动时会把自定义组件等代码全部注入，一个有上百个组件的项目，真正首屏用到的可能不到三分之一，其余注入时间都是白付的。开启按需注入后，只注入当前页面声明的组件与行为，页面越多收益越大。但收益不是白拿的：注入行为变了，任何「隐式依赖未声明组件」的写法都会暴露出来，这正是必须做兼容回归的原因。先把 启动上线流程清单 里的启动耗时基线测出来，有基线才知道优化有没有效果。
二、开启前的评估：三件事缺一不可
结论句：基础库覆盖率、关键路径名单、回滚方案，三件事在开启前就要落到纸面。
| 评估项 | 达标口径 | 常见错误 |
|---|---|---|
| 基础库覆盖 | 按后台用户分布确认覆盖率达到团队门槛再开 | 不看分布直接全量开，旧客户端出兼容问题 |
| 关键路径名单 | 首页、支付、下单等路径列成清单逐条压测 | 只测首页，支付页变慢上线后才发现 |
| 组件声明 | 页面用到的组件全部显式声明，无隐式依赖 | 依赖未声明组件的「顺带」注入被切掉 |
| 回滚方案 | 配置可关闭，发版节奏里写明回退步骤 | 出问题才发现没有快速回退手段 |
插件页面和特殊渲染引擎的行为要单独验证，不能默认与普通页面一致；平台规则细节以当期文档为准。
三、开启后的回归：两轮缺一轮不放量
结论句：第一轮压首屏关键路径的耗时，第二轮盯低端机的稳定性，两轮都过再灰度。
第一轮在主流机型上对比开启前后的启动耗时与首屏渲染耗时，确认「变快的是启动、变慢的没有」——个别项目出现过启动变快、关键路径交互反而变迟的情况，原因是组件注入延迟到了页面切换时。第二轮找低配真机跑完整主流程，低端机内存与调度更敏感，最容易暴露懒注入的时序问题。两轮结果记录成数据，用 灰度发布注意事项 的口径小流量放量，观察线上启动耗时分布稳定后再全量。
四、落地五步
结论句：按五步走，每步都有产出物，跳步的代价会在上线后补回来。
- 评覆盖：拉基础库用户分布，确认按需注入的支持率达标，不达标先做降级预案。
- 开配置：加上 lazyCodeLoading，同时梳理全部页面的组件声明，清掉隐式依赖。
- 压路径：按关键路径名单逐条压测，对比开启前后的启动与首屏数据。
- 测低端：低配真机回归完整主流程，重点看页面切换与首次渲染表现。
- 留开关：保留关闭配置的发版预案，放量期间盯性能监控，异常立即回退。
五、避坑清单
这三条坑都出在「想一口吃成胖子」：
- 别不做回归全量开：注入行为是全局变更，任何一条没压过的路径都可能变慢或报错。
- 别只看启动数字：启动快了不算赢，关键路径交互没变慢才算赢，两组数据一起看。
- 别不留回滚：性能优化必须可逆，没有回滚方案的变更不该上线。
六、常见问题 FAQ
开了按需注入，Skyline 渲染引擎页面要单独测吗？
要。渲染引擎与注入机制叠加后的行为需单独真机验证，确认无异常再纳入放量范围，不要默认兼容。
插件页面受影响吗？
插件的代码加载有自己的机制，涉及插件的页面要单独回归一遍，确认注入策略与插件加载不冲突。
用户基础库版本旧怎么办？
旧基础库不生效时走默认注入，属于自动降级；要做的是确认降级路径下功能正常，而不是强迫用户升级。
这个和 GEO 地理位置配置有关系吗？
没有。按需注入是代码加载策略；涉及门店位置展示的页面，其数据生效靠后台地理位置配置（地址、经纬度、服务类目），与地域 SEO 无关。
收益怎么向业务方证明？
用灰度期间的分位数启动耗时对比说话：对比开启前后的启动耗时分布与转化率变化，数据达标再全量，别用感觉汇报。
