H5 的门，本就不一样
把同一个功能做成 WebView 里的 H5 页面，再做成一个小程序，权限表现会截然不同。H5 活在受标准 Web 安全模型约束的浏览器引擎里：navigator.geolocation 给出的是粗略位置，在老旧安卓 WebView 上直接失败；相机的 getUserMedia 被网关拦截或禁用；支付则被甩到外部收银台。而小程序版本通过原生桥接调用同样的意图，往往一次就成。
这不是代码缺陷，是容器使然。H5 要透过浏览器的权限层去谈判能力；小程序握有的是平台级的能限白名单，runtime 把它直接映射到底层原生模块。
原生桥接到底是什么
runtime 通过一套统一的、经过审核的 API 表面——大家熟悉的 wx.* 家族——暴露设备与平台能力，而不是让每个网页再用浏览器重新谈判一次访问权。在这套表面背后，桥接把调用路由到原生层：支付、精确定位、相机与扫码、蓝牙与 NFC、文件系统、生物识别。每一项能力都事先声明、经平台审核，并以持久、细粒度的权限授予，而不是每次会话的浏览器弹窗。
桥接也是小程序手感能逼近原生 App 的原因。图像、二维码识别、OCR、模型推理这类重计算，可以推到原生层执行，结果再经同一通道返回。原生插件的存在，正是为了突破 WebView 的限制，拿到与原生相当的硬件能力。
差距在哪里显现
| 能力 | WebView 里的 H5 | 小程序 runtime（原生桥接） |
|---|---|---|
| 支付 | 外部收银台或跳转，流程割裂 | 一次调用、上下文内原生支付 |
| 定位 | navigator.geolocation 粗略，常失败 | 经平台审核的精确定位 |
| 相机与扫码 | getUserMedia 受限，常被拦截 | 原生 chooseImage 与 scanCode |
| 蓝牙与 NFC | 不可用或极受限 | 原生桥接模块 |
| 身份 | OAuth 多重跳转与手动点按 | login 加一键手机号 |
| 生物识别 | Web 上无 | 原生硬件级认证 |
这个模式在每个推出小程序 runtime 的平台都反复出现：桥接，正是把「Web 勉强能做」变成「程序直接就做」的那一步。
一个表面，胜过逐页谈判
统一的、经审核的 API 表面意味着开发者写一次 wx.requestPayment，就能跨设备、跨宿主 App 生效，而不必维护一整套浏览器降级、JS-SDK 签名与域名白名单。它也意味着平台能在边界执行策略——能力由审核授予，而非由谁提供文档决定——这正是超级 App 需要的信任模型。
Cross Mini App 怎么用
Cross Mini App 给程序一套原生桥接，把支付、定位、相机、连接、身份通过一个一致的 wx.* 式表面暴露出来，并在执行前按策略校验。你的代码调用一项能力；runtime 把它映射到运行所在设备上的对应原生模块。你拿到原生能力，却不必写原生代码；用户拿到一个不从缝隙里漏掉的流程。
这就是借浏览器的钥匙与握着自己的钥匙的区别：一个盼着门开，另一个直接转动它。
