信号，从来都不保险
大多数移动时间花在「还好，直到不好」的网络上——两站之间的地铁、开球时的球场、乡间公路、漫游边境。对刷新持仓的券商、接单的骑手、扫码的店员来说，信号掉下去的那一刻，恰恰是屏幕必须还能工作的时刻。同一台手机上两种模型表现天差地别，而差距是用白屏来衡量的。
H5 只能祈祷连接不断；小程序则是设计成连接只是可选项。
H5 每次打开都重拉整个世界
H5 页面是从 URL 拉取的文档，每次打开都是与网络的一次重新谈判。浏览器为每个源付出 DNS、TCP、TLS 握手，再链式拉取 HTML、CSS、JS、图片，每一步都等上一步。这代价不是理论：HTTP Archive 2025 Web Almanac 测得移动端页面中位总重 2,164 KB，其中 22 个独立的 JS 请求、约 646 KB 脚本。在弱网下，每一个请求都可能卡住，而单个阻塞渲染的样式表或脚本会把首屏扣为人质。
结果在真实数据中可见：同一报告称移动端 首字节时间（TTFB） 仅 44% 页面达到「良好」，移动端 总阻塞时间（TBT） 中位达 1,916 毫秒——第 90 百分位高达 7,555 毫秒。页面看起来已加载，主线程却忙得无法回应一次点击。在抖动剧烈的移动网络下，长尾又长又飘，白屏是连接不配合时的默认失败形态。
小程序，只向网络要数据
小程序不会在每次打开时重新拉取自身。包——框架、外壳、首屏——在之前的启动里就已下发并缓存，往往靠预测或预下载规则在信号好时完成。用户点击时，UI 从本地资源绘制，只有少量 JSON 数据请求走网络。那些笨重、易失败的资产根本不在关键路径上。
runtime 还给程序浏览器页面缺少的明确工具。微信文档规定网络请求默认超时 60 秒（可按调用或全局配置），而 onNetworkStatusChange 让程序侦测到掉线并切换行为——展示缓存数据、把动作入队、等链路恢复再重试——而不是把用户晾在空白页。preloadRule 分包预下载规则在连接健康时就把下一屏取回，导航永远不必等弱链路。
韧性从哪来
- 预缓存包：外壳与首屏在本地，可见 UI 无需网络往返即可打开。
- 数据面小：只有实时请求暴露在弱链路上——样式表、框架、图片都不在内。
- 网络感知：runtime 上报信号变化，程序能优雅降级而非盲目重试。
- 可预测的弱网表现：资产已在设备，体验退化成「数据延迟几秒」，而不是整屏白屏。
逐项对比
| 维度 | H5 / 移动网页 | 小程序 |
|---|---|---|
| 打开时走网络的内容 | HTML + CSS + JS + 图片 | 仅实时数据（JSON） |
| 移动端中位体量 | 总重约 2,164 KB，JS 约 646 KB | 包已缓存，请求仅 KB 级 |
| 打开时掉信号 | 资源加载完前白屏 | UI 从缓存绘制，数据重试 |
| TBT 暴露（移动中位） | 1,916 ms；p90 达 7,555 ms | 逻辑/网络与绘制隔离 |
| 网络感知 | 多半要手搓，甚至没有 | 内建状态 API + 超时控制 |
| 退化形态 | 二元：加载成功或空白 | 优雅：缓存视图 + 入队调用 |
对你的流程意味着什么
对任何发生在真实世界里的流程——闸机核销、地推成交、地下室的行情刷新——网络韧性是「完成动作」与「死屏」之间的差别。H5 也能到达同一终点，但只能靠手搓并长期维护 service worker、缓存策略、重试层，而这多数页面根本没做。小程序默认就拿到这种韧性形态，因为移动端最容易崩的那一环（资源下载）它早就提前完成了。
Cross Mini App 的位置
Cross Mini App 是「韧性默认」模型下的 runtime 与开放 catalog。你只需按标准 API 面构建一次小程序，它便在每一个嵌入的宿主里继承已预缓存的包与完整的数据层，于是屏幕照常打开、缓存视图照常在，即便信号微弱。网络变成可选项，而非地基。H5 仍是门，小程序则是信号闪烁时依旧亮着的房间。
