最近给 Windows 主机换上了 HyperX Cloud III S Wireless 无线耳机。
实际使用时遇到了一个不算严重、但很影响体验的问题：
耳机开机后，我希望 Windows 自动切换到耳机；耳机关机后，则自动切回显示器音频输出。
看起来应该是 Windows 自带就能处理的事情，但实际并不是。
最终我通过读取耳机 USB Dongle 的 HID 状态，做了一个常驻后台脚本，实现了真正意义上的：
耳机开机
→ 自动切换到 HyperX Cloud III S Wireless
耳机关机
→ 自动切换回 G27M7Pro下面记录完整排查和实现过程。
1. 问题：耳机关机后，Windows 仍认为设备在线
我的音频结构是：
HyperX Cloud III S Wireless
└─ 2.4 GHz USB Dongle
G27M7Pro 显示器
└─ NVIDIA HDMI/DP Audio
└─ 显示器音频输出HyperX 使用的是 2.4 GHz USB Dongle。
问题在于：
耳机本体关机后，USB Dongle 并不会从 Windows 消失。
在 Windows 的音频输出列表里，仍然可以看到：
耳机 (HyperX Cloud III S Wireless)这是因为 Windows 看到的实际上是 Dongle 提供的 USB Audio Endpoint。
因此：
耳机关机
≠
USB 音频设备断开Windows 没有收到设备移除事件，自然也就不会自动切回显示器。
拔掉 USB Dongle 倒是会触发切换，但显然不适合作为日常方案。
2. 思路：不要检测音频设备，直接检测耳机本体状态
既然 Windows 的音频设备状态不能反映耳机是否开机，那么就需要绕过 Audio Endpoint。
比较合适的办法是：
USB Dongle
↓
HID 接口
↓
查询耳机与 Dongle 的实际连接状态找到过一个针对 Cloud III / Cloud III S 的开源实现，它的核心思路也是通过 HyperX Dongle 的 HID 接口查询连接状态。
不过直接运行后出现了两个问题。
3. 第一个问题：我的 Dongle PID 不一样
参考实现使用的是：
VID = 03F0
PID = 06BE但在我的机器上执行：
Get-PnpDevice -PresentOnly |
Where-Object { $_.InstanceId -match 'VID_03F0' } |
Format-Table Status, Class, FriendlyName, InstanceId -Auto得到的实际设备是：
USB\VID_03F0&PID_02CC也就是说，我这只 Cloud III S Wireless 的 Dongle 是：
VID: 03F0
PID: 02CCWindows 同时能看到多个 HID Collection：
COL01
COL02
COL03
COL04
COL05
COL06这说明至少存在不同硬件/固件版本，不能直接假定所有 Cloud III S 都使用同一个 PID。
4. 找到正确的 HID 接口
使用 pywinusb 枚举 03F0:02CC 后，一共发现 6 个 HID Collection。
进一步打开后读取 usage_page：
[0]
usage_page=0x1c0
usage=0x1
[1]
usage_page=0x170f
usage=0x202
[2]
usage_page=0xc
usage=0x1
[3]
usage_page=0xff13
usage=0x1
[4]
usage_page=0xb
usage=0x5
[5]
usage_page=0xffc0
usage=0x202关键在第一个：
usage_page = 0x1C0
usage = 0x01这正好和参考实现使用的接口一致。
所以虽然 PID 从 06BE 变成了 02CC，HID 协议本身看起来仍然兼容。
5. 验证耳机开关状态
接下来通过 0x1C0 接口发送 HID Report：
buf = [0x00] * 64buf[0] = 0x0Cbuf[1] = 0x02buf[2] = 0x03buf[3] = 0x01buf[4] = 0x00buf[5] = 0x02然后读取返回包中的：
data[6]实际测试结果非常稳定。
耳机关机：
byte[6]=0耳机开机并和 Dongle 建立连接：
byte[6]=2因此可以直接转换为：
connected = data[6] >= 2实际响应速度很快，耳机开关后基本可以立即判断状态。
6. 意外问题：pywinusb 枚举 HID 要 30 秒
这里还遇到了一个比较奇怪的问题。
执行：
hid.HidDeviceFilter( vendor_id=0x03F0, product_id=0x02CC).get_devices()在我的 Windows 环境下大约需要：
30 秒但一旦枚举完成：
device.open()几乎是瞬间完成的。
也就是说瓶颈不在 HID 通信，而在 pywinusb 的设备枚举。
这意味着原先这种设计：
每隔几秒
→ 启动 Python
→ 枚举 HID
→ 查询一次
→ 退出完全不可用。
如果每次查询都要重新枚举，所谓的“每 3 秒检查一次”实际上可能要几十秒。
7. 改为常驻进程
解决方法很简单：
只枚举一次。
程序启动时：
启动
↓
枚举 HID，大约 30 秒
↓
找到 usage_page 0x1C0
↓
保持设备 Handle
↓
持续发送状态查询之后无需重新枚举。
我的轮询周期最终使用：
POLL_INTERVAL = 0.5也就是每 500ms 查询一次。
但只有在状态发生变化时才执行音频切换：
if state != last_state: ...因此不会每 500ms 修改一次 Windows 默认设备。
8. Windows 音频切换
Windows 端使用 AudioDeviceCmdlets：
Install-Module AudioDeviceCmdlets -Scope CurrentUser查看音频设备：
Get-AudioDevice -List |
Where-Object Type -eq 'Playback'我的两个目标设备分别是：
HyperX Cloud III S Wireless
G27M7Pro手动测试：
$hyperx = Get-AudioDevice -List |
Where-Object {
$_.Type -eq 'Playback' -and
$_.Name -like '*HyperX Cloud III S Wireless*'
} |
Select-Object -First 1
Set-AudioDevice -ID $hyperx.ID显示器同理：
$monitor = Get-AudioDevice -List |
Where-Object {
$_.Type -eq 'Playback' -and
$_.Name -like '*G27M7Pro*'
} |
Select-Object -First 1
Set-AudioDevice -ID $monitor.ID两边都可以立即完成切换。
9. 最终自动切换逻辑
于是最后的逻辑就非常简单：
HyperX Dongle
│
▼
HID usage 0x1C0
│
┌────────┴────────┐
│ │
byte[6] >= 2 byte[6] == 0
│ │
▼ ▼
耳机已连接 耳机未连接
│ │
▼ ▼
HyperX G27M7ProPython 里核心部分类似：
state = response[0] >= 2if state != last_state: if state: set_audio_device("HyperX Cloud III S Wireless") else: set_audio_device("G27M7Pro") last_state = state最终体验就是：
按下耳机电源键
→ 耳机连接
→ Windows 自动切换 HyperX
关闭耳机
→ Dongle 检测到断连
→ Windows 自动切回 G27M7Pro不需要打开 Windows 音量面板，也不需要拔 Dongle。
10. 后台运行与自启动
测试稳定后，我把脚本移动到了：
%LOCALAPPDATA%\HyperXAudioSwitch而不是继续放在 %TEMP%。
目录大致是：
HyperXAudioSwitch/
├─ hyperx_auto_switch.py
└─ .venv/然后使用 Windows 计划任务在登录时启动：
$dst = "$env:LOCALAPPDATA\HyperXAudioSwitch"
$action = New-ScheduledTaskAction `
-Execute "$dst\.venv\Scripts\pythonw.exe" `
-Argument "`"$dst\hyperx_auto_switch.py`"" `
-WorkingDirectory $dst
$trigger = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME这里使用的是：
pythonw.exe而不是：
python.exe这样后台运行时不会弹出终端窗口。
最终实现：
Windows 登录
↓
后台启动脚本
↓
首次枚举 HID
↓
持续保持 Dongle 连接
↓
监听耳机开关
↓
自动切换音频11. 最终结果
目前方案的行为符合预期：
唯一比较特殊的是：
pywinusb在我的机器上第一次枚举 HID 需要约 30 秒。
不过由于程序采用常驻设计，这个开销只会在程序启动时发生一次，对日常使用基本没有影响。
一点总结
这个问题本质上不是“Windows 不会自动切换音频”，而是：
耳机本体已经关机
但 USB Dongle 仍然存在
↓
Windows Audio Endpoint 没有发生断开
↓
系统根本不知道应该切换所以解决它的关键也不是继续折腾 Windows 音频策略，而是往更底层走一层：
直接读取 Dongle 的 HID 状态。
至少在我这只：
HyperX Cloud III S Wireless
VID_03F0
PID_02CC上，usage_page 0x1C0 可以非常稳定地判断耳机本体是否已经连接。
对于这种“无线设备本体和 USB 接收器生命周期不同”的硬件，这种思路其实也适用于很多类似场景。