事件循环不直接处理蓝牙连接，仅调度任务；蓝牙操作由web bluetooth api通过promise和事件异步实现，状态变更依赖微任务（成功/失败）和宏任务（断开事件）触发，需主动监听事件而非轮询。
JavaScript 的事件循环本身不直接处理蓝牙设备连接状态，它只负责调度和执行任务（宏任务、微任务）。蓝牙连接的底层操作由浏览器的 Web Bluetooth API 实现，而该 API 是基于 Promise 和事件驱动的异步接口，其状态变化最终通过事件循环被 JS 代码感知和响应。
蓝牙连接是异步操作，依赖 Promise 和事件
调用 navigator.bluetooth.requestDevice() 或 device.gatt.connect() 返回的是 Promise。这些操作由浏览器原生模块（如操作系统蓝牙栈）执行，JS 引擎不阻塞等待，而是立即返回并继续执行后续同步代码。当原生层完成连接或失败时，会将对应的 fulfill 或 reject 推入微任务队列，由事件循环在当前同步任务结束后处理。
- 成功连接后，
.then()回调进入微任务队列，优先于下一轮宏任务执行 - 连接失败时，
.catch()同样作为微任务被调度 - 连接断开（如设备关机、超出范围）会触发
device.addEventListener('gattserverdisconnected', ...)，该事件回调属于宏任务，进入任务队列等待执行
连接状态需主动监听，不能轮询或假设实时性
Web Bluetooth API 不提供“同步读取当前连接状态”的方法。你无法通过 device.gatt.connected 实时判断（该属性只在 GATT 连接建立后为 true，但断开后不会自动更新，需靠事件捕获）。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 正确做法：在
gattserverdisconnected事件中重置状态、清理资源、触发 UI 更新 - 避免使用
setInterval轮询device.gatt?.connected—— 它可能滞留旧值，且浪费资源 - 可结合
device.watchAdvertisements()（若支持）监听广播变化，辅助判断设备是否在附近
事件循环中的实际执行顺序示例
假设用户点击“连接”按钮：
- 同步执行
requestDevice()→ 浏览器弹出设备选择框（UI 线程挂起 JS，但不阻塞事件循环） - 用户选择设备后，原生层开始连接流程，JS 继续运行（此时无阻塞）
- 连接成功 → 原生层通知 JS 引擎 → 将
then回调推入微任务队列 - 当前同步代码执行完 → 事件循环清空微任务队列 → 执行
then中的device.gatt.connect() - GATT 连接成功 → 再次触发微任务 → 进入服务发现逻辑
- 若中途断开 → 触发
gattserverdisconnected（宏任务）→ 下一轮事件循环执行该回调
保持状态一致性的小建议
由于连接/断开事件可能在任意时刻被事件循环调度，建议用明确的状态变量 + 单一可信源管理：
- 定义一个
bluetoothState = { connected: false, device: null, server: null }对象集中维护 - 所有状态变更（连接成功、断开、错误）都通过统一函数更新，并触发自定义事件或更新 UI
- 在发起新操作前检查
bluetoothState.connected，而不是重复调用原生 API - 对重复连接请求做防抖（例如禁用按钮直到 Promise settle），避免并发导致状态混乱
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
