Web Bluetooth二次调用writeValue后自动断连，求连接持久化方案

我之前做Web Bluetooth项目时也碰到过类似的诡异断连问题，结合你的场景（Mac 10.13.3 + Chrome 64，修改过官方Android BLE外设模拟器），给你几个实用的排查方向和解决方案：

• 确保特征引用不被垃圾回收
  Web Bluetooth的设备、服务、特征对象如果失去了代码中的持续引用，浏览器的垃圾回收机制可能会悄悄释放它们，导致连接意外断开。你要把保存的特征对象存到全局变量里，或者放在一个不会被销毁的实例对象中，别让它只存在于requestDevice的回调局部作用域里。比如：

  // 全局变量保存特征引用
  let targetCharacteristic = null;
  
  navigator.bluetooth.requestDevice(...)
    .then(device => device.gatt.connect())
    .then(server => server.getPrimaryService(...))
    .then(service => service.getCharacteristic(...))
    .then(characteristic => {
      targetCharacteristic = characteristic;
      // 第一次writeValue
      return characteristic.writeValue(...);
    });
  
  // 后续动作触发时调用
  function onActionTriggered() {
    if (targetCharacteristic) {
      targetCharacteristic.writeValue(...).catch(err => console.error(err));
    }
  }
  

• 检查外设端的连接超时配置
  你修改了Android BLE外设模拟器，可能需要确认模拟器里的连接超时参数是否设置合理。有些BLE外设会在一段时间无交互后主动断开连接，或者在特定操作后触发断开逻辑。你可以在模拟器代码里调整连接超时的时长，或者添加一个简单的心跳机制——每隔几秒发送一个小数据包，让外设认为连接处于活跃状态。

• 升级Chrome和系统版本
  Chrome 64是比较早期的版本了，Web Bluetooth在这个版本里存在一些已知的兼容性bug，比如特征引用失效导致的断连问题。建议你升级到较新的稳定版Chrome，同时如果条件允许，也可以升级Mac OSX系统（比如到10.14及以上），系统自带的BLE栈更新后也能减少连接不稳定的情况。

• 规范writeValue的调用逻辑
  二次调用writeValue前，先检查设备的连接状态：

  function onActionTriggered() {
    if (!targetCharacteristic || !targetCharacteristic.service.device.gatt.connected) {
      // 设备已断开，先重新连接
      targetCharacteristic.service.device.gatt.connect()
        .then(() => targetCharacteristic.writeValue(...))
        .catch(err => console.error(err));
      return;
    }
    // 确保前一次writeValue完成后再执行下一次
    targetCharacteristic.writeValue(...).catch(err => console.error(err));
  }
  

  避免并发调用writeValue，异步操作要按顺序执行，防止链路层出现冲突导致断开。

• 利用Chrome的BLE调试工具定位问题
  在Chrome地址栏输入chrome://bluetooth-internals/，这个页面可以查看BLE连接的全生命周期日志，包括断开连接的具体原因（比如设备主动发起断开、链路层错误、超时等）。通过日志能快速定位到底是前端代码问题，还是外设端的问题。

内容的提问来源于stack exchange，提问作者Cyrus