Web 蓝牙连接失败？三步快速排查浏览器兼容性与设备状态

连不上。

真的，那种对着屏幕发呆，看着加载图标转圈却毫无反应的挫败感，每个搞物联网前端的人都尝过。你写了完美的代码，调用了 navigator.bluetooth.requestDevice，结果用户反馈说“根本搜不到”。

别急着去翻堆栈溢出上的陈年旧帖。

很多时候，问题不在于你的逻辑有多复杂，而在于那些容易被忽视的基础环境。浏览器权限没给对？设备处于错误的广播状态？还是说这该死的浏览器版本压根就不支持你要用的那个特性？

咱们把那些繁琐的调试工具先放一边。

今天只聊最直接的。借助几个在线的小工具，通过三个简单的步骤，就能把浏览器兼容性以及设备状态这块硬骨头给啃下来。不需要你去进行额外的软件安装工作，也不用在本地搭建复杂的测试环境。

第一步：确认浏览器是否真的“愿意”干活

你以为你用了 Chrome 就万事大吉了？

太天真了。

哪怕是 Chrome，要是运行在非 HTTPS 环境下，或者是在某些特定的隐私模式当中，Web Bluetooth API 也会直接罢工。它不会大声告诉你为什么，它只是默默地返回一个 Promise rejection，让你在那猜谜。

首先要做的，就是借助在线检测页面，去验证当前浏览器环境到底有没有开启蓝牙访问的权限通道。

打开一个专门用于检测 Web Bluetooth 支持度的页面。这类页面通常会尝试调用底层的 API 接口，然后直接把结果甩在你脸上。

要是页面上显示"Supported"，那好办，说明浏览器内核是认账的。

可要是显示"Not Supported"，那就得好好琢磨一下缘由了。是不是地址栏里没有那把小锁头（即 HTTPS 协议）？是不是你在关于 flag 的页面里把实验性功能给关了？

记住，Web Bluetooth 不是你想用就能用的。它被严格限制在安全上下文当中。

把地址从 http:// 改成 https://，有时候就能让原本死气沉沉的扫描按钮突然活过来。这个细节，坑过太多人。

第二步：扫描附近的“隐形”设备

浏览器认账了，接下来就得看设备给不给面子。

很多开发者在这一步栽跟头，是因为他们误以为只要设备开了机，就能被扫到。

大错特错。

蓝牙设备要想被 Web API 发现，必须处于一种特定的广播状态。对于耳机来说，可能是长按配对键后的闪烁状态；对于某些自定义的 IoT 传感器，可能需要它在广播包里面塞进特定的 Service UUID。

这时候，你需要借助一个能够发起主动扫描的在线工具。

这种工具会弹出一个原生的设备选择框。注意，是原生的。浏览器为了安全，不允许网页静默扫描，必须得有人为的交互动作来触发。

点击“开始扫描”或者类似的按钮。

如果列表里空空如也，别慌。

先问问自己：设备真的进入配对模式了吗？有些设备，像某些品牌的键鼠，一旦超过几十秒没人理它，就会自动退出广播状态以节省电量。你得重新去进行激活操作。

还有，过滤条件设对了吗？

如果你在代码里指定了 acceptAllDevices: false 并且列出了一堆 services，那么那些没有广播这些特定服务 UUID 的设备，就算就在你鼻子底下，浏览器也会装作看不见。

试着把过滤条件放宽。

把 acceptAllDevices 设置为 true，看看能不能扫到一堆乱七八糟的设备名字。要是这样能扫到了，那就说明问题出在你的过滤逻辑上，而不是设备本身挂了。

这一步的核心，就是把“搜不到”这个模糊的问题，拆解成“没广播”还是“被过滤”这两个具体的技术性缘由。

第三步：验证数据传输的稳定性

能连上，不代表能干活。

这是另一个常见的误区。很多人看到设备连接成功了，就以为大功告成，结果一写入数据，程序就崩，或者读取回来的全是一堆乱码。

连接建立只是握手成功，真正的考验在于后续的数据交互环节。

找一个提供读写测试功能的在线调试台。

这类页面通常会在连接成功后，展现出可供选择的 Characteristic（特征值）列表。你得从中挑出那个用来通信的特征值，然后尝试发送一段测试字符串，比如"Hello World"，或者十六进制的 0x01 0x02。

观察返回值。

要是设备立马回传了预期的数据，那恭喜，链路是通的。

要是超时了，或者根本没反应，这里面的水就深了。可能是 MTU（最大传输单元）的问题，导致数据包太大被截断；也可能是设备端的固件写得烂，处理不过来高频的请求；甚至有可能是字节序（Endianness）搞反了，你把大端当成了小端去解析。

在这个阶段，不要只盯着前端代码看。

很多时候，问题出在设备端没有正确地通知（Notify）或指示（Indicate）数据变化。你得确认设备是不是真的把数据推出来了，而不仅仅是前端没去订阅。

借助这些可视化的工具，你能清晰地看到每一次读写操作的时间戳和耗时。要是延迟高得离谱，几百毫秒甚至上秒，那你就得考虑是不是信号干扰，或者是蓝牙版本的协商出了问题。

别再盲目改代码了

遇到连接失败，第一反应不应该是去重构你的 JavaScript 逻辑。

停下来。

先用这些轻量级的在线手段，把外部环境给排除了。

浏览器支不支持？ 设备广没广播？ 数据通不通？

这三个问题搞清楚了，剩下的才是你代码里头的事儿。

大多数时候，你会发现，所谓的“疑难杂症”，其实就是设备没进配对模式，或者忘了开 HTTPS 这种低级错误。

把这些基础工作做到位了，再去进行复杂的业务逻辑开发，效率能极大程度上得到提升。

别让那些本可以避免的环境问题，浪费了你宝贵的调试时间。