那次悄悄弄坏旧 App 的升级
系统或某个核心库一升级，你一年前发出的原生 App 可能就直接打不开了。某个 API 被废弃、权限模型变更、渲染路径被移除——原本在生产环境好好的构建，此刻崩溃或被拒启动。平台向前走了，你的旧程序却没收到通知。
小程序运行时给出相反的承诺：它是版本化的，契约是「基于旧基础库发布的程序，在新运行时上仍保持可打开」。兼容性表面由运行时承载，程序无需追赶每一次平台变更以维持存活。
版本化兼容到底是什么
运行时暴露一个带 主.次.补丁 版本的基础库，平台保证更新的运行时仍能运行基于更旧基础库构建的程序。微信对此有明确文档：新能力以「最低基础库版本」为门槛，开发者用 wx.canIUse 或 wx.getAppBaseInfo 做兼容判断，而非假设某能力一定存在。支付宝+的基础库概览与涂鸦的更新日志同样声明这一原则——基础库在新增能力时「保持向后兼容」。微信甚至在每个客户端版本中同时内置当前与上一个稳定基础库，让旧程序持续完成初始化。
原生 App 则没有这种保证：一次系统升级就是一次破坏性变更，无论 App 是否准备好，都会落到用户头上。
差距在哪里体现
| 环节 | 原生 App | 小程序运行时（版本化） |
|---|---|---|
| 新平台版本 | 可能弄坏旧构建 | 旧基础库仍可运行 |
| 被废弃的 API | 崩溃或无法启动 | 特性检测，优雅降级 |
| 兼容性检查 | 逐设备、手动 | canIUse / 版本比较 |
| 稳定性保证 | 系统层无保障 | 向后兼容的基础库 |
| 程序生命周期 | 受系统支持绑定 | 受运行时契约绑定 |
结果是：已发布的程序不再因下一次平台发版而自带到期日。它会一直可打开，直到开发者主动放弃支持。
为什么「契约」胜过「指望」
版本化运行时意味着开发者一次发布即可信赖程序会随平台演进而持续运行，对新能力则做特性检测。它还意味着「基础库下限」是一项配置，而非赌注：开发者设定最低版本，其余由运行时接管。同一个程序在宿主升级后依然存活，在遵守基础库契约的每个宿主上都如此。
Cross Mini App 如何落地
Cross Mini App 为程序提供带明确兼容性契约的版本化运行时：基于旧基础库构建的程序在新运行时上仍保持可打开，对新能力做特性检测。你发布一份程序，运行时承诺它在下次升级后仍会启动。你不再为了保住昨天的构建而反复发版。
这就是「随系统过期」的 App 与「运行时承诺持续打开」的程序之间的区别。
