拖垮整个 App 的那次崩溃
内嵌一个 WebView，页面就和你的原生壳同处一个进程。一段失控脚本、一个内存溢出循环、一次渲染故障，不只是毁掉页面——它还能把整个 App 一起带走。用户失去的是你的 App，而不只是他打开的内容。
小程序运行时把每个程序隔离在自己的容器里。故障停在原地，宿主继续运行。
容器隔离是什么
运行时给每个程序一个有界的沙箱：自己的内存预算、自己的生命周期、一道不会漏进宿主的崩溃边界。Chrome 的站点隔离与 Android 的按进程 WebView 模型在浏览器层面描述了同一原则。微信记载了小程序独立渲染，OWASP 把隔离列为基线控制。
差距在哪里体现
| 环节 | WebView（共用进程） | 小程序运行时（容器） |
|---|---|---|
| 崩溃范围 | 整个 App | 单个程序 |
| 内存故障 | 能杀死宿主 | 限制在沙箱内 |
| 恢复方式 | 重启 App | 重启程序 |
| 波及半径 | 一切 | 一个容器 |
| 用户影响 | 会话丢失 | 留在宿主内 |
结果是一个只结束一块屏幕、而非一次会话的故障。
为什么隔离胜共命运
隔离意味着一个充满 bug 的程序无法把宿主一起拖垮，于是某个供应商的坏构建不会变成你的宕机。它也意味着恢复很便宜——重载程序而非整个 App——用户在宿主里的位置被保住。
Cross Mini App 如何落地
Cross Mini App 把每个程序跑在自己的沙箱里，于是崩溃被关在该程序内、宿主继续运行。某供应商的一份坏构建，只是那一家供应商的问题。你不再因为一个页面失去整个 App，而是默认就隔离了故障。
这就是会扩散的崩溃与会停下的崩溃之间的区别。
