商店审核税

每一次原生发版都交同一笔过路费：提交到 App Store 或 Google Play，等审核，盼它通过，再等用户去安装。行业剖析把这个周期定为每次更新 24 到 72 小时——这还在一个用户下载新包之前。对于一个紧急 bug 或转瞬即逝的市场窗口，三天就是永恒。

小程序运行时彻底取消了这笔税。加载你程式的容器是通过商店分发的，但你程式的代码不是。它走 CDN，由运行时拉取，意味着你更新程式时完全不碰宿主 App 的发版流水线。

热更新到底怎么跑

用户打开一个小程序时，容器把本地缓存和管理服务器上的最新版本比对。若有新包，就在后台下载、原子化换入——通常在下次冷启动时生效，当前这次会话用旧版本跑完，中途不会崩。微信的文档写得精确：每次冷启动静默异步检查，新版本下次启动生效；只有在设置了最低可用版本时，才会强制同步。

分离才是关键。容器运行时——稳定 API、安全强制、硬件访问——走商店；小程序代码——业务逻辑与表现层——走 CDN。两者解耦，平台就能在每次执行前按安全策略校验更新，在给你速度的同时把「敞开门」的风险关上。

原生做不到的四件事

  • 无用户摩擦。 用户从来看不到更新提示或安装界面，换包是静默的。
  • 即时回滚。 一个坏版本在控制台几分钟内部回退；下次启动即回退到上一包。腾讯的生命周期实践写道，手动与紧急回滚都可在约十分钟内全量生效。
  • 极小差量。 更新系统只下发变更文件——通常仅完整包的 10% 到 30%——所以弱网设备也能廉价地拿到修复。
  • 灰度发布。 按百分比、地区或用户群放行，让你在全面铺开前先验证，且全程无需再次提交商店。

节奏，逐项对照

维度原生 App小程序运行时
更新路径商店审核CDN 换包
典型时延24 到 72 小时分钟级
用户动作下载并安装无（静默）
回滚新发版 + 再审核控制台回退，分钟级
差量体积完整二进制10% 到 30%

原生那一列把每次修复变成项目；运行时那一列把它变成一次推送。

Cross Mini App 如何落地

Cross Mini App 让程式跑在一个从受治理 CDN 拉包、按策略校验、原子化换包的运行时上——于是你今晚发出的修复，明早就在用户侧生效，回滚只在一键之间。迭代速度不再是一种约束，而是一种优势。

这就是「商店门控的发版」与「持续迭代的服务」之间的区别：一个要许可才能改；另一个只是改，且安全地改。

参考来源