把网页做成一块屏很容易，但用它去够到设备很难。结账页或内容页在 WebView 里活得好好的；可一旦功能需要真正的硬件——蓝牙外设、NFC 标签、能真正唤醒手机的通知、App 关闭后还能跑的任务——Web 平台就够不到了。这道缺口叫「能力的天花板」，也正是 H5 小程序在需要调用设备时悄悄失去与原生竞争资格的地方。

网页看不全的设备

移动操作系统暴露了庞大的原生能力面：摄像头、生物传感器、蓝牙、NFC、精确定位、后台执行、本地通知、系统分享、健康与钱包框架。Web 平台只够到其中一小片，而且连这一小片也不均匀。Web Bluetooth、Web NFC、WebUSB、WebHID、Web Serial 这些 Web 标准都是 Chromium 独占的实验特性——Safari 里没有，多数应用内 WebView 里也没有。于是同一块 H5 屏，因渲染它的引擎不同表现就不同，「一次编写」的承诺恰好在功能需要设备的那一刻破了产。

跟着引擎走的能力地图

兼容性表把这道天花板写得很具体。Web Bluetooth 在 Chrome 和 Edge（含 Android 上的 Chrome）完全支持，但在 Safari、iOS 上的 Safari、以及 Android/iOS 的 WebView 里都没有支持（MDN）。Web NFC 能在 Android 上的 Chrome（89+）和 Android WebView（89+）读写标签，但在所有桌面浏览器和 iOS 上的 Safari 里缺席（MDN）。Web Push 在苹果平台上最刺眼：一位苹果 DTS 工程师确认「WebView 内的 App 不支持 Web Push 通知」。在 iOS 上，Web Push 只存在于用户「添加到主屏幕」的网页应用（iOS 16.4+），绝不会出现在别的 App 内 WebView 渲染的内容里。所以一个内嵌 H5 服务商家的流量 App，无法向这些商家承诺蓝牙配对、NFC 碰一碰、或可靠的推送——iOS 上不行，Android 上也不稳定。

脆弱的补丁：私有桥

团队能抓的救命稻草是 JS Bridge——每个超级 App 自己发明的私有通道，让 H5 调进原生代码。它能用，直到它不能用。每个宿主都在重复造轮子：不同的 API 形状、不同的权限叙事、不同的安全模型，以及一个新的注入与攻击面（本系列已经讲过）。Bridge 按宿主自己的节奏更新，而不是 Web 的节奏，于是它既偏离了文档化的 Web 平台，也彼此偏离。结果就是：能力存在，但碎片化、无治理、且无法在这个平台托管的海量小程序目录上做审计。

runtime 的解法

宿主自有 runtime 用一套标准化、经审核的能力 API 取代临时的桥。小程序不再各自去协商一条私有通道，而是通过一个一致、版本化、按权限隔离的接口去拿设备能力——蓝牙、NFC、推送、后台任务、摄像头、生物识别、本地通知、系统分享——在宿主支持的每个平台上表现一致。宿主定义小程序能请求什么，用户按能力授权，调用走平台可审计的路径。能力不再是一个个 App 的科研项目，而成了一项受治理的服务。

维度WebView宿主自有 runtime
原生可达一小片，且看引擎脸色一套一致的能力 API
蓝牙 / NFC仅 Chromium，iOS WebView 缺席设备允许处统一暴露
iOS 推送WebView 内不可用经宿主通道走原生推送
桥模型私有、每家不同、无治理标准化、经审核、按权限隔离
可审计性跨目录近乎为零每个能力一条被审计路径

本系列的贯穿主线是控制权。WebView 让你画出一块屏，却够不到屏背后的设备；runtime 让你通过一个自己定义的边界去够到设备。对于一个价值恰恰在于「手机能做的事」——付款、配对、碰一碰、通知——的流量 App，这道边界就是产品本身。

参考来源