那个不请自取的浏览器
加载一个 WebView，页面就继承了浏览器的全部能力：读存储、取定位、开相机、联网，往往只差一次用户早已习惯点允许的弹窗。这里没有持久的、按程序划分的边界——渲染内容的引擎，同时也握着钥匙。恶意或粗心的页面直接拿走，用户事后才察觉。
小程序运行时把默认行为反转过来：敏感 API 全部挡在已声明作用域、用户授权、可吊销之后。程序只申请它需要的那一项，而不是一次性拿走全部。
作用域权限模型是什么
运行时把敏感能力（定位、相机、通讯录、支付）只通过已声明、具名的作用域暴露。用户首次使用时逐一对作用域授权，授权绑定到该程序而非整个宿主。微信以 scope 授权模型记载了这一点；Apple 的 App 审核指南与 OWASP 都把作用域加用户同意视为移动端的基本卫生；W3C 的 Permissions 规范则为开放 Web 写下了同样的先问再访问范式。
差距在哪里体现
| 环节 | WebView（静默取用） | 小程序运行时（作用域） |
|---|---|---|
| API 访问 | 加载即继承 | 声明作用域加授权 |
| 用户控制 | 习惯性点允许 | 按程序授权，可吊销 |
| 波及范围 | 整个引擎 | 单个程序 |
| 审计线索 | 难以追溯 | 已声明作用域清单 |
| 吊销方式 | 清除 App 数据 | 设置里一键吊销 |
结果是 WebView 从未有过的边界：程序只能做用户明确允许的事。
为什么问胜过取
作用域化、可吊销的模型意味着一个泄漏或恶意的程序无法静默窃取设备能力——权限清单可见，授权可移除。它也意味着宿主 App 自身的数据留在程序触及范围之外，因为程序从未拿到引擎级的宽泛访问。
Cross Mini App 如何落地
Cross Mini App 把程序跑在这样一个运行时里：每个敏感 API 都被挡在已声明作用域加用户授权之后，并在宿主设置中支持吊销。程序恰好拿到它申请的那些能力，不多不少。你不再继承浏览器的钥匙，而是按需授予访问。
这就是页面拿走引擎之力与程序赢得用户之信之间的区别。
