Windows下检测USB设备最可靠方式是调用SetupDiGetClassDevs枚举指定功能类设备，如GUID_DEVCLASS_DISKDRIVE查U盘、GUID_DEVCLASS_HIDCLASS查键盘等，而非仅用GUID_DEVCLASS_USB（对应主机控制器）；需链接setupapi.lib并调用SetupDiDestroyDeviceInfoList释放句柄。
Windows下用SetupDiGetClassDevs检查USB设备是否存在
直接调用Windows API是最可靠的方式，SetupDiGetClassDevs 可以枚举指定类别的即插即用设备。USB设备没有统一的“USB设备类”，得按具体子类查，比如大容量存储（GUID_DEVCLASS_DISKDRIVE）、HID（GUID_DEVCLASS_HIDCLASS）或通用USB设备（GUID_DEVCLASS_USB）。
常见错误是只查 GUID_DEVCLASS_USB，结果返回空——因为该GUID对应的是“USB控制器”（如xHCI主机控制器），不是你插的U盘或键盘。实际要检测外设，得查其功能类，或者用更宽泛的 GUID_NULL + 过滤 USB\ 开头的硬件ID。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 包含
<windows.h>和<setupapi.h>，链接setupapi.lib - 调用
SetupDiGetClassDevs(&GUID_DEVCLASS_DISKDRIVE, nullptr, nullptr, DIGCF_PRESENT | DIGCF_DEVICEINTERFACE)判断是否有U盘类设备在线 - 遍历设备时用
SetupDiEnumDeviceInterfaces+SetupDiGetDeviceInterfaceDetail提取DevicePath，再用QueryDosDevice确认是否挂载了盘符（避免只枚举到未分配盘符的设备） - 别忘了调用
SetupDiDestroyDeviceInfoList释放句柄，否则多次调用后可能句柄泄漏
Linux下读取/sys/bus/usb/devices判断USB设备热插拔状态
Linux不提供“当前有没有USB设备”的原子查询接口，但 /sys/bus/usb/devices/ 目录下每个子目录对应一个已识别的USB设备（包括根集线器）。只要该目录非空，就说明至少有一个USB设备被内核识别。
立即学习“C++免费学习笔记（深入）”；
注意：这个目录反映的是内核视角的设备树，不是用户态“是否可用”。比如USB摄像头被 v4l2 占用、U盘被卸载，目录依然存在。真正要判断“用户可交互的USB设备”，得结合 /proc/mounts（查挂载）、/dev/video*（查视频设备）等路径。
实操建议：
- 用
opendir("/sys/bus/usb/devices")检查目录是否可打开且至少含两个条目（.和..不算，通常还有1-0或2-1.2这类编号目录） - 避免轮询整个目录树做字符串匹配；只需确认存在任意一个形如
[0-9]-[0-9]*的子目录即可（排除usb1、usb2这类主机控制器节点） - 不要依赖
/proc/bus/usb—— 该路径在现代内核（≥3.0）默认关闭，需加载usbfs模块且权限受限
跨平台检测不可行，必须分系统处理
C++标准库不提供硬件枚举能力，也没有跨平台USB抽象层。Boost.Process、libusb 等第三方库也不能“检测插入与否”——它们只能在设备已存在时与之通信。libusb 的 libusb_get_device_list 返回的是当前已连接设备列表，但它本身不触发重扫描，也不通知热插拔事件。
所以所谓“检测是否插入”，本质是：Windows查SetupAPI设备快照，Linux读sysfs快照。两者都是瞬时状态，无法替代事件监听。
容易踩的坑：
- 误以为
libusb_init+libusb_get_device_list能自动感知新插入设备——它不会，必须手动重调才能更新列表 - 在macOS上试图复用Linux逻辑——
/sys根本不存在，得用IOServiceAddMatchingNotification配合IOUSBDevice匹配字典，且需链接IOKit.framework - 把“设备存在”等同于“用户可访问”——例如Windows下U盘被BitLocker锁定、Linux下权限不足导致open()失败，设备虽在，但程序无法使用
简单场景下用文件系统变化间接推断
如果目标只是知道“有没有新U盘挂载”，比精确枚举USB设备更轻量的办法是监控挂载点变化。这绕开了设备枚举复杂度，且对用户意图更贴近。
Windows可用 FindFirstVolume/FindNextVolume 对比前后卷列表；Linux可读 /proc/mounts 并过滤 vfat、ntfs、exfat 等常见U盘文件系统类型。
关键限制：
- 无法区分USB设备和其他块设备（如NVMe SSD、SD卡槽）
- 需要定期轮询（间隔建议 ≥500ms），不能依赖事件——除非你愿意写Windows的WM_DEVICECHANGE消息循环或Linux的inotify监听
/proc/mounts（不推荐，该文件是procfs伪文件，inotify不可靠） - macOS需解析
diskutil list -plist输出，稳定性差，不建议用于生产
真正稳定的方案永远要绑定操作系统原生机制。想用一套代码覆盖三端，最后只会变成一堆条件编译和运行时分支，维护成本远高于分平台实现。
