HTML无法直接监听蓝牙耳机连接状态或提示音，因浏览器沙箱限制和API局限性，只能通过间接方式概率性推断设备类型，且存在大量误判漏判。
HTML 没有“函数”能直接监听蓝牙耳机的连接状态或提示音
浏览器环境无法通过 HTML 或 DOM API 主动监听蓝牙耳机插拔、提示音播放、甚至音频设备类型（有线/蓝牙）。navigator.mediaDevices.enumerateDevices() 只能列出当前可用音频输出设备，但不区分物理类型——蓝牙耳机和 USB 声卡在返回结果里都只是 kind: "audiooutput"，且多数浏览器（尤其是 Safari 和旧版 Chrome）对蓝牙设备的 label 返回空字符串或模糊标识（如 "Default Output Device"），无法可靠识别。
这意味着你不能靠 HTML/JS 函数“监听提示音是否从蓝牙耳机发出”，更无法捕获系统级提示音（如 iOS 连接提示音、Windows 蓝牙配对音）——这些音由操作系统底层触发，完全绕过网页音频上下文。
想检测用户是否用了蓝牙耳机？只能间接推断
目前唯一可行路径是结合 MediaStream + 设备枚举 + 用户交互做概率性判断，但存在大量漏判和误判：
- 调用
navigator.mediaDevices.getUserMedia({ audio: true })后，再执行navigator.mediaDevices.enumerateDevices()，检查deviceId是否与之前已知的蓝牙耳机 ID 匹配（需用户首次手动选中并记录） - 监听
devicechange事件，发现新增audiooutput设备后，提示用户“检测到新音频设备，请确认是否为蓝牙耳机”，再引导其点击setSinkId()测试播放 - 尝试用
AudioContext创建简单 tone，调用audioElement.setSinkId(deviceId)指定输出，并观察是否静音（部分蓝牙耳机在 A2DP 模式下不支持低延迟音频通路，setSinkId会失败并抛出NotSupportedError）
注意：setSinkId 在 iOS Safari 完全不可用；Android Chrome 对蓝牙耳机的支持依赖系统音频路由策略，常 fallback 到扬声器。
立即学习“前端免费学习笔记（深入）”；
提示音播放本身不受外设类型控制，但受音频上下文状态限制
网页播放提示音（比如 play() 一个 <audio></audio>）能否响，关键不是“耳机类型”，而是：AudioContext 是否已激活、用户是否完成手势触发、目标设备是否被系统静音或独占。
常见陷阱：
- 自动播放被拦截：未响应用户点击就调用
audio.play()，Chrome 会静音，Safari 直接拒绝 —— 这和是不是蓝牙耳机无关 - 蓝牙耳机处于“通话模式”（HFP）：此时仅支持单声道、低采样率语音，
AudioContext创建或decodeAudioData可能失败，报错DOMException: Unable to decode audio data - 系统级静音开关：iOS 控制中心的“铃声/提醒”静音、Windows 的应用音量单独设为 0，都会让提示音消失，但网页 JS 完全无感知
真要辅助开发调试？用桌面工具补位更实际
浏览器沙箱决定了它不适合做外设状态监控。如果目的是验证提示音是否从蓝牙耳机正常播出，建议放弃纯前端方案：
- 开发阶段用
chrome://media-internals查看当前音频路由：搜索audio_output_device_id，对比设备名是否含 “Bluetooth” 字样（仅限桌面 Chrome） - macOS 上用
system_profiler SPBluetoothDataType或第三方工具如Bluetooth Explorer观察连接状态变化 - Android 开发可借助
adb shell dumpsys audio抓取实时音频输出设备日志
网页层能做的，只是确保音频资源加载正确、触发时机合法、错误处理覆盖 NotSupportedError 和 NotAllowedError —— 至于声音最终从哪出来，得交给系统和用户去决定。
