配了三年蓝牙，每次读数据都要装 App——今天 Chrome 把这件事彻底变了

接了三年蓝牙设备，每次读取数据都要靠原生 App——今天 Web Bluetooth 把这件事彻底变了。

这个坑我踩过。以前想读取一个心率带的数据，必须让用户装一个原生 App，光应用商店审核就要等三天。现在 Chrome 自己把这条路打通，网页直接和蓝牙设备对话，不需要任何安装。

Web Bluetooth API 是什么

Web Bluetooth API 是 W3C 制定的标准，让浏览器可以直接和 Bluetooth Low Energy (BLE) 设备通信。它的工作模式基于 GATT (Generic Attribute Profile)，这是 BLE 设备的标准通信架构。

三个核心接口：

• Bluetooth.requestDevice() — 弹出设备选择器，用户挑选要连接的设备
• Bluetooth.getDevices() — 获取当前源已授权的设备列表
• Bluetooth.getAvailability() — 检测设备是否支持蓝牙

拿到设备实例之后，通过 GATT 服务层逐层向下：

const device = await navigator.bluetooth.requestDevice({
  filters: [{ services: ["heart_rate"] }]  // 心率服务
});

const server = await device.gatt.connect();
const service = await server.getPrimaryService("heart_rate");
const characteristic = await service.getCharacteristic("heart_rate_measurement");

// 监听数据更新
characteristic.addEventListener("characteristicvaluechanged", (event) => {
  const value = event.target.value;
  const heartRate = value.getUint8(1);  // 解析心率值
  console.log(`当前心率: ${heartRate} BPM`);
});

await characteristic.startNotifications();

设备断开时 gatt.disconnected 事件会触发，可以在这里做重连逻辑。

哪些场景真正能用

这个 API 的价值不在于「连接」，而在于「无安装门槛」。

健康数据采集是最直接的场景。心率带、血压计、血氧仪——这类设备在公司内部健康活动、远程医疗初筛、教学场景里，每次让人装原生 App 都是转化流失。现在一个网页，扫码即用，用完即走。

智能家居的场景也在变。以前配一个 BLE 灯具，需要下载厂商指定的 App。现在可以直接做一个通用的控制面板，把不同品牌的设备统一接入。不需要每个厂商都做一个 App。

工业场景里，读取设备状态、传感器数据、资产标签——以前靠专人现场巡检或昂贵的专用设备。现在一个平板 + 浏览器，现场人员自己就能读。

安全模型不是可选项

这个 API 的安全限制是强制的，不理解清楚就是在给自己埋坑。

HTTPS 是硬性要求，本地开发时 localhost 除外。这不只是建议——浏览器在非安全上下文中直接拒绝调用。

用户授权也是强制的。requestDevice() 会弹出原生的设备选择器，开发者无法绕过。这意味着用户在设备上必须主动选择「配对」，网页没有静默连接的权限。

还有三个重要限制：只能连接前台标签页中的设备，后台网页的蓝牙会话会被挂起；不支持后台服务；大多数操作系统只允许一个网页同时连接一个 GATT Server。

这些限制是隐私保护的一部分，但也意味着 Web Bluetooth 无法替代需要持续后台监控的原生应用。

浏览器支持现状

这是选择这个 API 时最需要考虑的现实因素。

支持的浏览器：Chrome Android (89+)、Edge (Chromium)、Samsung Internet。

不支持的浏览器：Safari iOS（截至 2026 年仍无计划支持，这是最大的坑）、Firefox Android（未实现）。

这意味着如果你面向的主要用户群是 iOS，这个 API 目前用不了。这也是为什么它至今不是 Baseline 标准。

但 Android 市场的份额足够大，而且正在增长。对于企业内部工具、健康筛查场景、智能家居配置面板，Android 用户覆盖率是可用的。

实际落地怎么考虑

不是所有 BLE 设备都能连。Web Bluetooth 只支持标准 GATT 服务，不支持专有协议。连接前需要确认设备公开了哪些服务，常用的有：

• 心率服务 (Heart Rate, 0x180D)
• 电池服务 (Battery Service, 0x180F)
• 设备信息服务 (Device Information)

对于不支持的设备，可以先在代码里做能力检测：

if (!navigator.bluetooth) {
  console.error("当前浏览器不支持 Web Bluetooth API");
  // 降级方案：显示安装提示或引导使用原生应用
}

渐进增强的思路在这里很适用：先做功能检测，不支持时降级到扫码或手动输入，支持时启用蓝牙连接。体验分层不过度。

配了三年蓝牙，现在发现这件事根本不需要原生 App——只要用户手里是 Android 手机，Chrome 自己能对话，前端工程师自己能做数据采集工具，不用等客户端团队排期。

下一步可以先拿一个心率带或 BLE 传感器实测一遍，从 requestDevice 开始跑通整个链路。踩过一遍之后，真实场景的适配方案自己就清楚了。