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

连不上。

真的，那种对着屏幕发呆，看着进度条转圈最后弹出一个冷冰冰"Connection Failed"的感觉，太糟心了。

不管是想连个蓝牙耳机听歌，还是作为开发者在调试那些该死的物联网传感器，Web Bluetooth API 本该是座桥梁，结果往往成了堵墙。

别急着砸键盘。

绝大多数时候，问题不在你的代码逻辑有多烂，也不在那块开发板是不是烧了，而是你忽略了浏览器那套繁琐得令人发指的权限机制，或者是设备本身的状态压根就没准备好进行交互。

咱们把那些虚头巴脑的理论抛开，直接切入正题。

这就好比你去敲一扇门，门没开，你得先搞清楚是门锁坏了，还是你根本没站在正确的门口，亦或是屋主根本不想理你。

第一步：确认浏览器真的“愿意”跟你玩

首先得泼盆冷水。

不是所有浏览器都支持这套东西。

如果你还在用某些老旧的 Edge 版本，或者指望在 Firefox 上直接跑通原生的 Web Bluetooth 功能，那趁早打消这个念头。

谷歌 Chrome 以及基于 Chromium 内核的浏览器（像新版 Edge、Brave 这些）才是这块领域的主力军。

但这还不够。

即便你用的是最新版的 Chrome，要是没走 HTTPS 协议，一切免谈。

浏览器出于安全考量，会把本地回环地址 localhost 当作特例放行，可一旦你把项目部署到服务器上，却忘了配置 SSL 证书，那个 navigator.bluetooth 对象就会直接变成 undefined。

这时候你去调用扫描方法，控制台里连个报错都懒得给你吐，直接静默失败。

很多人在这一步就卡住了，折腾半天代码，最后发现仅仅是因为网址栏左边少了一把小锁。

所以，在进行任何设备扫描工作之前，务必先把地址栏检查一遍。

要是看到“不安全”的提示，那就赶紧去搞个证书，或者老老实实退回 localhost 环境去开展调试工作。

还有个小细节容易被忽视。

有些用户会在浏览器设置里手动关闭蓝牙权限，或者在企业管控环境下，管理员直接把这项功能给禁用了。

这种情况下，你再怎么刷新页面也是白搭。

得让用户去浏览器的站点设置里，把蓝牙这一项的开关重新打开，允许网站去请求访问蓝牙设备的权限。

第二步：设备状态与扫描策略的博弈

好了，环境没问题了，浏览器也准备好了。

接下来就是重头戏：扫描。

很多初学者写的代码，一上来就调用 requestDevice，然后期待设备立马跳出来。

天真。

设备得先“广播”才行。

这就好比你在嘈杂的酒吧里找人，对方得先开口说话或者挥舞手臂，你才能看见他。

如果那个物联网设备处于休眠状态，或者它的广播间隔设置得极长，你的网页就算把嗓子喊破了也扫不到它。

这里有个常见的误区。

你以为只要设备开了机就能连，其实不然。

很多低功耗蓝牙（BLE）设备为了省电，在没有配对过或者没有特定触发条件时，是不会持续发送广播包的。

你得物理按一下设备上的按钮，让它进入“可被发现”的模式，也就是通常说的配对模式。

只有在这个短暂的时间窗口内，浏览器才有机会捕捉到它的信号。

再说说过滤条件。

你在代码里写的 filters 参数，简直就是个筛子。

要是你指定了 services 数组，比如 ['battery_service']，那么浏览器只会把广播包里明确包含了这个服务 UUID 的设备展示给用户。

要是设备固件写得不规范，漏发了这个字段，哪怕它明明有电池服务，也会直接被浏览器过滤掉，仿佛人间蒸发了一样。

这时候，试着把过滤条件放宽。

甚至可以先不填任何 filters，只保留 acceptAllDevices: true，看看能不能把设备逼出来。

当然，这样做在生产环境是不推荐的，毕竟会让用户看到一堆无关设备，但在排查故障阶段，这是判断是不是过滤条件写死了的最快手段。

记住，acceptAllDevices 必须配合 optionalServices 一起使用，否则你连上了也读不到数据，那也是白忙活一场。

第三步：权限弹窗背后的隐形杀手

假设设备出现在了列表里，用户也点击了连接。

接下来发生的交互，往往是最容易出岔子的地方。

浏览器会弹出一个原生的选择框，让用户确认连接。

这一步看似简单，实则暗藏玄机。

有些用户手快，直接点了取消，或者在之前的会话中选择了“不再询问”，导致后续的连接请求被浏览器默默拦截。

更麻烦的是权限的生命周期。

Web Bluetooth 的权限是跟标签页（Tab）绑定的，而不是跟域名绑定的。

这意味着，你要是刷新了页面，之前建立的连接就会断开，权限虽然还在，但需要重新发起连接请求来建立新的链路。

还有一种情况，特别让人抓狂。

连接成功了，服务也获取到了，但在尝试读取特征值（Characteristic）的时候，报错了。

提示说"Permission denied"或者类似的权利不足。

这通常是因为你在连接时，没有在 optionalServices 里声明你要访问的那个服务 UUID。

浏览器是个守门员，它不会让你随意窥探设备的所有秘密。

你必须在发起连接的那一刻，就明确告诉浏览器：“我要连这个设备，并且我还需要访问除了主服务之外的这几个服务。”

要是漏写了，后面再怎么补救都没用，只能断开重连，并且把缺失的服务补进列表里。

这个设计初衷是为了保护隐私，防止恶意网站偷偷读取你的心率或者位置信息，但对于开发者来说，确实增加了不少配置的复杂度。

你得把整个交互流程在脑海里过一遍：扫描、选择、连接、发现服务、获取特征、读写数据。

任何一个环节的元数据不匹配，都会导致链条断裂。

稳定性验证与数据传输的深坑

连上了不代表万事大吉。

真正的考验在于数据传输的稳定性。

蓝牙信号这东西，脆弱得很。

稍微有点干扰，或者距离远了一点，数据包就可能丢失。

你在本地测试好好的，一到现场就歇菜，这种情况简直不要太多见。

建议在做完基础连接测试后，马上进行持续的数据读写压力测试。

不要只发一次指令就完事。

要循环发送，观察丢包率，看看在长时间运行下，连接会不会莫名其妙地断开。

如果发现频繁断连，除了检查硬件天线和周围环境干扰外，还得看看你的代码处理机制。

有没有做好错误捕获？

当 gatt.server.connected 变成 false 的时候，你的界面有没有给出明确的提示，引导用户重新进行操作？

很多糟糕的体验就在于，程序崩了，界面上却还显示“已连接”，用户点什么都没反应，最后只能强制刷新页面。

这种反馈缺失，是让用户觉得产品“不稳定”的主要原因。

另外，关于 MTU（最大传输单元）的问题也得提一嘴。

虽然 Web Bluetooth API 目前对 MTU 的控制还比较有限，主要依赖浏览器和系统的默认协商结果，但你得知道，单次写入的数据量是有限制的。

要是你试图一次性塞进去几千字节的数据，大概率会被截断或者直接报错。

得学会把大数据包拆解成小块，分批次地进行发送工作。

这虽然增加了一些代码量，但却是保证数据完整性的必要手段。

写在最后

排查 Web Bluetooth 的连接问题，本质上就是一场跟浏览器安全策略以及硬件物理特性的博弈。

别总想着是一行代码写错了。

多去看看浏览器的控制台日志，多去观察设备的指示灯状态，多去理解权限授予的时机。

这三步走下来：查环境、看状态、核权限，基本上能解决掉九成以上的连接故障。

剩下的那一成，可能就是真的硬件坏了，或者是固件里有无法逾越的 Bug。

那时候，也就只能认栽，换个设备试试了。

毕竟，技术再牛，也修不好一块彻底报废的芯片。

保持耐心，细致观察，这才是搞定这类问题的不二法门。