切换页面活动后 Nordic BLE devkit 连接断开致Web应用崩溃如何解决？

你遇到的跳转后BLE断开、已获取的service/characteristic失效，本质和JavaScript的this绑定/闭包问题无关，是Web平台的固有机制导致的：

• Web Bluetooth API 的所有资源（包括已建立的GATT连接、BluetoothDevice实例、service、characteristic对象）生命周期完全绑定当前文档上下文，硬跳转触发的整页卸载会强制回收所有这类绑定原生接口的资源，不存在跨页面保留的可能。
• 你当前用的location.replace()属于整页导航，会完全销毁第一页的JS执行栈和内存对象，哪怕两个页面引用同一个公共JS文件，第二页加载时JS也是全新初始化的，第一页存在内存里的设备、服务引用不会被带到新页面。

• Web Bluetooth 资源生命周期：所有通过navigator.bluetooth.requestDevice()获取的设备对象、GATT连接、服务/特征实例，都属于浏览器宿主提供的原生绑定对象，没有跨文档持久保留的原生支持。
• 硬跳转的上下文销毁逻辑：location.replace/location.href这类整页跳转，和单页应用的前端路由切换有本质区别——前者会彻底销毁当前文档的所有执行上下文，包括JS内存中的对象、绑定的事件，后者只会切换DOM，不会销毁上下文。
• Web存储的能力边界：localStorage/sessionStorage这类存储接口仅支持存储可序列化的纯数据（字符串、数字、可转JSON的普通对象），无法存储绑定原生接口的宿主对象，把这类对象存进存储再取出来只是无实际能力的普通JS拷贝，调用方法会直接报错。
• 跨文档通信机制：浏览器提供的同源跨页信息传递接口，包括BroadcastChannel、storage事件监听、window.postMessage，这类接口仅能传递可序列化的结构化数据，不能传递带原生绑定的特殊对象。

方案1：改造为单页结构（最适配新手开发场景，改动量最小） #

完全取消两个独立HTML的硬跳转逻辑，把第二页的内容整合到同个HTML中，通过DOM显隐做页面切换：

• 第一页完成BLE扫描、连接、拿到service/characteristic后，把这些对象存在公共JS的全局状态变量中，因为没有触发文档卸载，连接和对象引用不会被销毁。
• 原有的跳转按钮触发逻辑替换为DOM操作：比如给两个页面对应的区块加统一的page-section类，切换时通过修改hidden属性控制显示隐藏，完全不触发文档加载流程。
• 第二页的初始化逻辑（比如绑定按钮的BLE操作），在第二页区块首次显示时执行即可，不需要修改公共JS中的BLE通信逻辑。

方案2：跨页传递纯配置，新页面重建设备连接 #

如果必须保留两个独立HTML的跳转逻辑，不要尝试跨页传递characteristic对象，只传递可序列化的配置信息，在新页面重新建立连接：

• 第一页连接成功后，把纯配置数据存入sessionStorage，示例结构如下：

  sessionStorage.setItem('bleConnectionConfig', JSON.stringify({
    deviceId: connectedDevice.id,
    targetServiceUuid: '你的目标服务UUID',
    targetCharacteristicUuid: '你的目标特征UUID'
  }))
  

• 第二页加载时，先读取sessionStorage中的配置，结合Web Bluetooth的重连能力，重新获取设备、建立GATT连接、读取对应的service和characteristic——注意浏览器的安全策略要求重连操作必须由用户交互触发，不能在页面加载完成后静默执行。
• 这种方案下需要接受跨页跳转时连接会短暂断开的事实，无法实现连接无感知延续。

方案3：Service Worker托管连接（进阶方案，不适合新手初期开发） #

如果需要跨页面、甚至页面后台运行时持续保持BLE连接，可以引入Service Worker作为中间层，由SW持有BLE连接的引用，两个页面通过消息通道和SW交互完成设备通信。这类方案需要处理SW的生命周期、作用域权限、消息通信兼容等问题，踩坑成本较高，不建议开发初期使用。

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