WMI监听USB设备插入延迟高（1–3秒）但可获取型号、厂商等详情，需用__InstanceOperationEvent和DeviceID唯一识别；RegisterDeviceNotification响应快但无设备信息，需后续查询。
WMI方式监听USB设备插入，Win32_PnPEntity查得全但延迟高
用WMI最直接，适合需要识别具体设备型号、厂商、驱动状态的场景。但别指望实时——从插上到触发事件通常有1–3秒延迟，Windows底层要等PnP管理器完成枚举和驱动加载。
-
ManagementEventWatcher必须用__InstanceOperationEvent配合WHERE TargetInstance ISA 'Win32_PnPEntity'，只监听Win32_DeviceChangeEvent收不到USB设备细节 - 过滤条件写成
AND TargetInstance.PNPClass = 'USB'不够准，有些USB设备归类为Media或Ports，建议用TargetInstance.Name LIKE '%USB%'或检查TargetInstance.DeviceID是否含VID_/PID_ - 事件回调里别直接弹窗或阻塞UI线程，WMI事件在后台线程触发，更新UI需
Invoke或Dispatcher.BeginInvoke
RegisterDeviceNotification响应快但只能获知“有变化”，不带设备信息
这是Windows API原生方案，毫秒级响应，但只告诉你“某个设备类变了”，不告诉你变的是哪个USB口、什么设备。适合做快速开关控制或状态同步，不适合做设备识别。
- 必须先调用
FindWindow拿到窗口句柄（哪怕隐藏窗），再传给RegisterDeviceNotification，控制台程序默认没消息循环，会收不到通知 - 关注
DBT_DEVICEARRIVAL和DBT_DEVICEREMOVECOMPLETE，但lParam是DEV_BROADCAST_DEVICEINTERFACE结构体指针，强转前务必检查dbch_devicetype == DBT_DEVTYP_DEVICEINTERFACE - 收到通知后想查设备详情？得立刻用
SetupDiGetDeviceInterfaceDetail再查一遍，不能依赖通知里的字段
USB设备识别靠DeviceID，不是名称或描述
用户看到的“SanDisk Cruzer Blade”可能重名，但每个USB存储设备的DeviceID（如USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_BLADE&REV_1.00080912124712000000&0）唯一。识别逻辑必须基于它，否则多插几个同型号U盘就乱套。
- WMI中从
TargetInstance.DeviceID取值，注意它含反斜杠，C#字符串要双写或用@前缀 - 对比时忽略大小写和末尾
&0这类实例编号（不同插拔次数会变），用DeviceID.Substring(0, DeviceID.LastIndexOf('&'))截断更稳 - 不要用
TargetInstance.Name去匹配，重命名设备或系统语言切换后内容就不可靠
权限与兼容性：管理员权限不是必须，但Win10/11上WinUSB设备可能被拦截
普通用户权限足够监听大多数USB设备，但某些使用WinUSB驱动的设备（如自定义HID、CDC类设备）在Win10 1803+之后默认禁止非管理员访问，监听能触发，但后续SetupDi查询会失败并报ERROR_ACCESS_DENIED。
- 检查
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usbccgp\Start是否为3（启用），禁用会导致部分USB设备根本不出现在WMI中 - 如果目标设备是自研硬件，提前在INF里加
ExcludeFromSelect=1并签名驱动，否则Win10可能自动换用usbccgp而非你的驱动 - 测试时拔掉所有非必要USB设备，避免
Win32_PnPEntity返回上千条记录拖慢查询
真正麻烦的是混合设备：一个USB接口连着Hub，Hub下又插了键盘+U盘+串口模块。WMI事件会发三次，但DeviceID层级关系藏在Parent字段里，得递归查才能确认是不是同一物理端口下的变动。
