Qt实现Windows U盘与光驱安全弹出：设备树、IOCTL与线程实践

前年冬天给某实验室做一套采集上位机，交付前一周需求方临时加了两个按钮：一个“弹出光盘”，一个“安全弹出U盘”。我当时的判断是这活儿半小时能收工，结果这两个按钮在测试机上时灵时不灵，前后折腾了整整两天才稳定下来。更尴尬的是中途我一度用了一个网上很流行的写法，测试时把一块演示U盘上的分区表搞乱了，虽然数据最后找回来了，但那半天的心跳我现在还记得。

这件事让我意识到，“Qt弹出U盘及光盘”这个标题看着像是个三行代码的小需求，实际跨了三个完全不同的层面：外壳层交互、卷管理层、设备树层。三者用的 API 完全不是一套东西，混用就会出现“返回成功但盘还在”这种最恶心的结果。这篇内容我打算把这两年在这个点上踩过的坑、验证过的调用顺序、以及能在 Qt 工程里直接抄的代码全部摊开讲。适合正在写 Windows 桌面工具、需要做设备管理面板、或者单纯被DeviceIoControl折磨过的同行看。哪怕你只做光驱托盘弹出，前面关于句柄权限和阻塞调用的部分也值得读一遍。

1. 先分清“弹出”到底指哪一件事

1.1 三种语义：托盘、卷、设备节点

绝大多数人第一次写这个功能，脑子里只有一个词：eject。但在 Windows 的设备栈里，eject 至少对应三种完全不同的操作，作用对象、影响范围、成败判定都不一样。

第一种是介质弹出，作用于光驱这类有物理托盘的设备。你把IOCTL_STORAGE_EJECT_MEDIA发给光驱的卷句柄，驱动会让托盘弹出来，盘片仍然在托盘上，重新推回去或者发IOCTL_STORAGE_LOAD_MEDIA就能收回。这个操作的作用范围只有“这一张盘”。

第二种是卷卸载，作用于 U 盘上的某一个分区。系统会把该卷的缓存刷盘、解除盘符挂载，但物理设备还插在 USB 口上，设备管理器里依然能看到它。这一步是“安全删除”里最容易被误解的部分——很多人以为卸载完就能拔了，其实设备还处于上电状态。

第三种是设备请求移除，这是真正意义上“安全删除硬件”那套逻辑，对应CM_Request_Device_Eject。它会沿着设备树向上遍历，通知所有持有该设备句柄的组件（包括文件系统、卷管理器、各种过滤驱动）开始释放资源，全部同意之后才把设备标记为可以拔出。只有走到这一步，界面上那句“可以安全移除”才是成立的。

我最初犯的错就是把第一种当成了万能钥匙。IOCTL_STORAGE_EJECT_MEDIA发到 U 盘句柄上，有些 U 盘主控会返回TRUE，你满心欢喜地提示“已安全弹出”，用户一拔，文件系统还在写缓存里，第二次插上去就变成需要 chkdsk 的状态。这个坑的隐蔽性在于API 返回成功了，如果你的日志只记返回值，根本查不出来。

1.2 从 Qt 到内核的调用链路

Qt 本身没有任何弹出设备的能力，QStorageInfo只能告诉你哪些卷挂载了、剩余空间多少、文件系统类型是什么，它是只读的查询接口。所以真正干活的部分必须落到 Win32 API 上，Qt 在这里承担的是三件事：字符串转换、线程调度、界面刷新。

调用链路大致是：QString 形式的盘符（比如"E"）→ 拼成\\.\E:这种设备路径 →CreateFileW拿到内核对象句柄 →DeviceIoControl下发控制码，或者通过SetupDi*系列把设备树里对应的 DEVINST 找出来 →CM_Request_Device_Eject。

这条链路上有三个地方特别容易断。设备路径的拼写必须以\\.\开头，少一个反斜杠就变成普通文件路径，CreateFile会去找一个叫E:的文件然后失败。字符串必须走宽字符版本，Qt 的QString内部是 UTF-16，toStdWString()之后取c_str()是最省事的做法，不要在中途转成toLocal8Bit()，中文系统上盘符虽然是 ASCII，但设备接口路径里可能带非 ASCII 字符。还有链接库，SetupDi*系列在Setupapi.lib，CM_*系列在Cfgmgr32.lib，两个都要加，少一个就是一堆 LNK2019。

1.3 为什么我不推荐流行写法SHFileOperation

网上能搜到的最短写法是用SHFileOperationW配FO_DELETE，把盘符根目录作为源路径传进去，加上FOF_NO_UI | FOF_NOCONFIRMATION，外壳会替你走一遍“弹出”流程。代码确实短，五行搞定，很多人就这么用了。

我踩的坑就在这儿。这个调用的语义本质是“删除”，虽然传入驱动器根目录时外壳会做特殊处理转而调用弹出逻辑，但行为依赖外壳的版本和上下文。在资源管理器正常运行时它表现得像个弹出操作；在服务进程或者没有外壳上下文的会话里，它会真的尝试删除目录内容。我那次测试把演示盘的分区表搞乱，就是在一个被我改过启动方式的测试账号下触发的——外壳没有正常提供确认对话框，直接走了删除分支。

提示：任何依赖外壳特殊判断的写法，在非交互式环境里都是定时炸弹。上位机、后台服务、计划任务这些场景一律绕开SHFileOperation。

替代方案就是我下面要展开的两套：光驱用IOCTL_STORAGE_EJECT_MEDIA，U 盘用CM_Request_Device_Eject。前者清晰、后者正统，两者都不依赖外壳。

2. 打开驱动器句柄：路径、权限与失败重试

2.1\\.\X:和\\.\PhysicalDriveN的选择依据

CreateFileW打开设备有两种入口：卷级和设备级。卷级是\\.\E:，设备级是\\.\PhysicalDrive2。选哪个取决于你要做什么。

光驱弹出必须用卷级路径，因为IOCTL_STORAGE_EJECT_MEDIA是存储类驱动在卷设备对象上处理的控制码，你拿PhysicalDriveN的句柄发过去，行为就不确定了，有些驱动会忽略，有些会返回ERROR_INVALID_FUNCTION。

U 盘识别用卷级，但真正执行弹出需要设备级的DEVINST。这就是为什么流程上要先把卷打开、拿STORAGE_DEVICE_NUMBER、再去设备树里匹配。这个结构体里三个字段很有用：DeviceType告诉你介质类型，DeviceNumber是物理盘编号，PartitionNumber是分区编号。多分区的 U 盘，两个分区的DeviceNumber相同、PartitionNumber不同，所以匹配必须按DeviceNumber走，否则你从 E 盘找到的会是 E 盘那个分区的设备接口，弹出后 F 盘可能还挂着。

具体查询代码：

#include <windows.h> #include <winioctl.h> #include <QString> #include <QByteArray> static bool queryDeviceNumber(const QString &driveLetter, STORAGE_DEVICE_NUMBER *out) { const QString devPath = QString("\\\\.\\%1:").arg(driveLetter.at(0)); HANDLE h = CreateFileW(reinterpret_cast<const wchar_t *>(devPath.utf16()), GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, 0, nullptr); if (h == INVALID_HANDLE_VALUE) { h = CreateFileW(reinterpret_cast<const wchar_t *>(devPath.utf16()), 0, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, 0, nullptr); if (h == INVALID_HANDLE_VALUE) return false; } DWORD returned = 0; BOOL ok = DeviceIoControl(h, IOCTL_STORAGE_GET_DEVICE_NUMBER, nullptr, 0, out, sizeof(*out), &returned, nullptr); CloseHandle(h); return ok != FALSE; }

注意这里做了一次权限降级：先试GENERIC_READ，失败再试 0。这一步在实际环境里能救回不少设备。

2.2 权限位怎么给：一个被忽略的细节

CreateFileW的第二个参数是期望的访问权限。很多示例代码直接写GENERIC_READ | GENERIC_WRITE，这在光驱上经常失败，因为驱动器里有盘时，另一个进程可能正持有写独占；而驱动器里没盘时，有些驱动会直接拒绝GENERIC_WRITE。

我实测下来的推荐顺序是：光驱先用GENERIC_READ，失败退到 0；U 盘查询卷信息用GENERIC_READ，失败退到 0。访问权限 0 拿到的句柄虽然不能读写数据，但DeviceIoControl大部分存储类控制码仍然可以下发，因为内核检查的是句柄上的具体访问位，而不是“有没有权限”这种笼统概念。

还有一种更细的写法是用FILE_READ_ATTRIBUTES代替GENERIC_READ。这个位足够通过IOCTL_STORAGE_EJECT_MEDIA的检查，同时对介质状态的要求更宽松。我在一个只读光驱的场景里用FILE_READ_ATTRIBUTES成功弹出了托盘，而GENERIC_READ反而返回了ERROR_ACCESS_DENIED。

2.3ERROR_ACCESS_DENIED的真实来源

排查阶段我把这个错误码的来源分成了三类，处理方法完全不同。

第一类是介质被占用。某个进程正在读写盘上的文件，或者有一个打开着的文件句柄没关。这时候需要先把占用者找出来。我没有在程序里实现完整方案，太复杂，实际做法是给用户一个提示，让他用资源监视器查“关联的句柄”。如果你必须自动化，NtQuerySystemInformation那一套能拿到句柄列表，但实现成本很高。

第二类是权限位不匹配，就是上一节讲的，降级重试即可。

第三类是设备本身拒绝。比如某些读卡器在没插卡时对任何控制码都返回这个错误，或者 U 盘处于写保护状态。这一类只能靠预先检测规避，比如先判断GetDriveType的返回值和介质在线状态。

我的处理顺序是：先降级重试，失败就检查GetDriveType，再失败就查卷是否在线，最后才提示用户。这个顺序能把九成以上的误报挡在前面。

3. 光盘托盘的弹出与收回

3.1 先判断托盘里有没有盘

对空托盘发IOCTL_STORAGE_EJECT_MEDIA，行为取决于驱动：有些会弹托盘，有些直接返回ERROR_NOT_READY。为了界面提示准确，最好先探测介质状态。

最直接的探测是IOCTL_STORAGE_CHECK_VERIFY：

static bool isMediaPresent(HANDLE h) { DWORD returned = 0; BOOL ok = DeviceIoControl(h, IOCTL_STORAGE_CHECK_VERIFY, nullptr, 0, nullptr, 0, &returned, nullptr); if (!ok && GetLastError() == ERROR_NOT_READY) return false; return ok != FALSE; }

判断逻辑很朴素：返回成功就是有盘，返回ERROR_NOT_READY就是空托盘。其他错误码我按“不确定”处理，日志里记下来，界面上仍然允许用户点弹出，因为有些老光驱对CHECK_VERIFY的支持很差，误判成“没盘”反而挡住了正常操作。

IOCTL_STORAGE_CHECK_VERIFY2是 Vista 之后引入的版本，语义更严格，但兼容性上要考虑目标机器。我目前统一用老的，够用。

3.2 一旦设备忙，主线程就会被卡住

这是我这套代码里最值钱的一个改进点。DeviceIoControl默认是同步调用，光驱在转盘、寻道、或者驱动内部等某个锁的时候，这个调用可能阻塞几百毫秒到几秒。如果你的按钮点击槽函数里直接调它，整个 Qt 界面就僵住了，用户看到的是“程序卡死”。

两种解法。第一种是加FILE_FLAG_OVERLAPPED，传一个OVERLAPPED结构，用WaitForSingleObject配合超时等待：

HANDLE h = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, nullptr); OVERLAPPED ov{}; ov.hEvent = CreateEventW(nullptr, TRUE, FALSE, nullptr); DWORD returned = 0; BOOL ok = DeviceIoControl(h, IOCTL_STORAGE_EJECT_MEDIA, nullptr, 0, nullptr, 0, &returned, &ov); if (!ok && GetLastError() == ERROR_IO_PENDING) { DWORD wait = WaitForSingleObject(ov.hEvent, 3000); if (wait == WAIT_TIMEOUT) { CancelIo(h); // 关键，否则句柄关闭时会挂住 } else { GetOverlappedResult(h, &ov, &returned, FALSE); } } CloseHandle(ov.hEvent); CloseHandle(h);

这里CancelIo特别重要。如果你超时之后直接CloseHandle，内核会等这个未完成的 I/O 结束才真正释放句柄，结果还是卡住，只是卡的位置从DeviceIoControl挪到了CloseHandle，日志上看起来一模一样的时长，非常误导人。

第二种解法是塞进QThread或者QtConcurrent::run，界面不阻塞就行，超时控制仍然得靠上面的机制。我现在的做法是两者叠加：工作线程里跑带OVERLAPPED的实现，超时设 3 秒，超时后给界面抛一个“设备无响应”的信号，让用户自己决定要不要重试。

3.3 收回托盘与多光驱场景

收回用IOCTL_STORAGE_LOAD_MEDIA，跟弹出完全对称，注意它不是所有光驱都支持，笔记本的吸入式光驱基本都会返回ERROR_INVALID_FUNCTION，这个要在界面上做区分，不能当成故障。

多光驱的场景下，盘符可能漂移。机器上插了两个光驱、一个虚拟光驱，盘符是 D、E、F，顺序取决于 BIOS 枚举和挂载顺序，不是固定的。我的处理是不缓存盘符，每次操作前用QStorageInfo::mountedVolumes()重新扫一遍，按文件系统类型和驱动器类型筛选，然后让用户从下拉框里选。虚拟光驱（比如各种镜像挂载工具创建的那种）对IOCTL_STORAGE_EJECT_MEDIA的响应通常是“卸载镜像”，这个效果恰好也是用户想要的，所以不需要特殊排除。

4. U盘安全弹出：从盘符找到设备树节点

4.1 三级定位：卷 → 磁盘 → DEVINST

这是整个功能里最绕的部分，我把它拆成三级。

第一级，从盘符拿STORAGE_DEVICE_NUMBER，就是前面queryDeviceNumber干的事，得到DeviceNumber。

第二级，遍历系统里所有磁盘设备接口，找到IOCTL_STORAGE_GET_DEVICE_NUMBER返回的DeviceNumber和第一级一致的那个。遍历靠SetupDiGetClassDevs配GUID_DEVINTERFACE_DISK，DIGCF_PRESENT | DIGCF_DEVICEINTERFACE两个标志都要加，前者只枚举在线的，后者才是接口枚举而不是设备枚举。

第三级，从第二级拿到的SP_DEVINFO_DATA里取DevInst，喂给CM_Request_Device_Eject。

完整的实现：

#include <setupapi.h> #include <cfgmgr32.h> #include <devguid.h> #include <QByteArray> static bool ejectDiskByNumber(DWORD targetNumber, QString *vetoText) { HDEVINFO info = SetupDiGetClassDevsW(&GUID_DEVINTERFACE_DISK, nullptr, nullptr, DIGCF_PRESENT | DIGCF_DEVICEINTERFACE); if (info == INVALID_HANDLE_VALUE) return false; bool done = false; SP_DEVICE_INTERFACE_DATA ifd{}; ifd.cbSize = sizeof(ifd); for (DWORD i = 0; SetupDiEnumDeviceInterfaces(info, nullptr, &GUID_DEVINTERFACE_DISK, i, &ifd); ++i) { DWORD needed = 0; SetupDiGetDeviceInterfaceDetailW(info, &ifd, nullptr, 0, &needed, nullptr); if (needed == 0) continue; QByteArray raw(static_cast<int>(needed), 0); auto *detail = reinterpret_cast<PSP_DEVICE_INTERFACE_DETAIL_DATA_W>(raw.data()); detail->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA_W); SP_DEVINFO_DATA did{}; did.cbSize = sizeof(did); if (!SetupDiGetDeviceInterfaceDetailW(info, &ifd, detail, needed, nullptr, &did)) continue; HANDLE h = CreateFileW(detail->DevicePath, 0, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, 0, nullptr); if (h == INVALID_HANDLE_VALUE) continue; STORAGE_DEVICE_NUMBER sdn{}; DWORD got = 0; BOOL ok = DeviceIoControl(h, IOCTL_STORAGE_GET_DEVICE_NUMBER, nullptr, 0, &sdn, sizeof(sdn), &got, nullptr); CloseHandle(h); if (!ok || sdn.DeviceNumber != targetNumber) continue; PNP_VETO_TYPE vetoType = PnP_VetoTypeUnknown; WCHAR vetoName[MAX_PATH] = {}; CONFIGRET cr = CM_Request_Device_EjectW(did.DevInst, &vetoType, vetoName, MAX_PATH, 0); if (vetoText && vetoName[0]) *vetoText = QString::fromWCharArray(vetoName); done = (cr == CR_SUCCESS); break; } SetupDiDestroyDeviceInfoList(info); return done; }

4.2 句柄释放顺序和返回值判定

这份代码里有两个容易出问题的细节。

第一个是SetupDiDestroyDeviceInfoList。这个调用必须在所有SetupDi*操作完成后执行，包括你从SP_DEVINFO_DATA里已经取到DevInst之后。我见过有人在循环中间就释放了，后面还在用detail->DevicePath，结果行为不可预测。DevInst本身是个整数句柄，设备信息集释放后它仍然有效，但为了保险起见我把CM_Request_Device_Eject放在释放之前执行。

第二个是返回值的判定。CM_Request_Device_Eject返回CR_SUCCESS才代表设备树同意了移除请求，其余都是拒绝。最常见的拒绝值是CR_REMOVE_VETOED，意思是某个组件投了反对票，具体是谁反对记录在vetoName里。我做了一个映射，把常见的 veto 名字翻译成人话：

还有一个值需要单独说：CR_ACCESS_DENIED。这个不是设备拒绝，是权限问题。普通用户进程对某些设备节点执行移除请求会拿到这个，解决办法是提权，或者退而求其次只做卷卸载。

4.3 只卸载卷的降级方案

如果CM_Request_Device_Eject一直失败，用户又确实需要拔盘，可以退一步做卷卸载。用DeviceIoControl发FSCTL_DISMOUNT_VOLUME，把卷从文件系统里摘下来：

DWORD returned = 0; BOOL ok = DeviceIoControl(h, FSCTL_DISMOUNT_VOLUME, nullptr, 0, nullptr, 0, &returned, nullptr);

发之前必须先FSCTL_LOCK_VOLUME，否则大概率返回ERROR_ACCESS_DENIED。锁卷会强制关闭该卷上所有缓存的文件句柄，这一步有一定的破坏性——如果用户正在拷贝文件，拷贝会直接中断。所以我在界面上把这个操作做成二次确认，并且明确告诉用户“这会中断该盘上正在进行的所有读写”。

注意：锁卷成功后如果不再需要，务必发FSCTL_UNLOCK_VOLUME，否则卷会一直处于锁定状态，直到进程退出。我在早期版本里忘了这一步，用户反馈“弹出失败之后盘就打不开了”，查了很久才发现是锁没放开。

5. 把这套东西塞进 Qt 工程

5.1 线程模型：为什么必须离开主线程

前面说过DeviceIoControl可能阻塞，CM_Request_Device_Eject更麻烦，它会等待整条设备栈上的组件响应，实测中遇到过等待超过 8 秒的情况（一块老 U 盘，上面挂着实时扫描软件）。

我的做法是封装一个DeviceEjectWorker类，继承QObject，用moveToThread挪到工作线程，公开三个槽函数：ejectOptical(QString)、ejectRemovable(QString)、queryDevices()，各自通过信号回传结果和错误信息。

class DeviceEjectWorker : public QObject { Q_OBJECT public slots: void ejectRemovable(const QString &letter); signals: void finished(const QString &letter, bool ok, const QString &message); };

信号里带QString完全没问题，跨线程的信号槽在 Qt 里默认走队列连接，会自动做深拷贝。但不要在信号里传裸指针或者HANDLE，那些东西的生命周期在工作线程里，主线程拿到也不知道该怎么办。

还有一个细节：工作线程里创建的对象，销毁时必须在同一个线程里deleteLater，别在主线程直接delete。我在一个版本的退出逻辑里写错了，程序关闭时偶发崩溃，dump 里看到的是跨线程释放堆块。

5.2 字符串转换的边界

QString到宽字符，最干净的是toStdWString()，但它会构造一个std::wstring临时对象，取c_str()之后必须保证临时对象还活着。写成这样是错的：

const wchar_t *p = path.toStdWString().c_str(); // 临时对象析构，p 悬空

正确的写法是先把std::wstring存成一个局部变量，或者用reinterpret_cast<const wchar_t *>(path.utf16())。后者不产生拷贝，前提是path本身在调用期间不被修改、也不被析构。我在调用CreateFileW这种一次性的场景里用第二种，在需要多次复用的场景里用第一种。

反过来，从宽字符转QString用QString::fromWCharArray，注意要传长度或者确保源串以\0结尾。CM_Request_Device_Eject回填的vetoName是标准的以空字符结尾的缓冲区，直接传就行。

5.3 盘符列表的刷新策略

QStorageInfo::mountedVolumes()是一个静态快照，它不会自动更新。用户插拔 U 盘之后，你必须重新调一次才能拿到新状态。

两种刷新策略。定时器轮询最省事，QTimer设 1 到 2 秒，每次调mountedVolumes()比对盘符集合，有变化就更新界面。这个方案的代价是每秒扫一次卷列表，在机械硬盘多的机器上会有轻微开销，但实测可以接受。

另一种是监听WM_DEVICECHANGE，通过重写QWidget::nativeEvent或者QAbstractNativeEventFilter拿到消息，wParam等于DBT_DEVICEARRIVAL或DBT_DEVICEREMOVECOMPLETE时刷新。这个方案精准、无轮询开销，但需要注册设备通知才能拿到更细的信息（比如具体是哪个卷）。我目前用第一种，因为代码短、跨 Qt 版本稳定，而且 1 秒的延迟对交互体验影响很小。

界面上有一个必须处理的边界：盘符消失的时刻。如果在用户点击“弹出”之后、操作完成之前，盘符已经被其他因素摘掉了（比如用户自己拔了），你的CreateFileW会返回ERROR_FILE_NOT_FOUND。这个不算错误，应该给用户一个“设备已移除”的中性提示，而不是弹红色报错。

6. 实测踩坑清单与兼容性对照

6.1 错误码对照与处置

这两年攒下来的错误码处理表，直接对照着写switch就行：

要注意的是ERROR_NOT_READY在不同接口上的含义不完全一样。IOCTL_STORAGE_CHECK_VERIFY返回它表示空托盘，FSCTL_LOCK_VOLUME返回它表示卷还没就绪。处理逻辑要分开写，不能共用一个分支。

6.2 不同介质的差异对照

不是所有看起来像 U 盘的东西都能用同一套逻辑。我测过的几类设备表现差异挺大：

第二行是我早期犯的错。我当时用GetDriveType == DRIVE_REMOVABLE作为“是否可弹出”的判断条件，结果 USB 移动硬盘全部漏掉，用户反馈“这个盘为什么不能弹”。后来改成判断磁盘设备的总线类型，用IOCTL_STORAGE_QUERY_PROPERTY配StorageDeviceProperty，看STORAGE_DEVICE_DESCRIPTOR里的BusType字段，等于BusTypeUsb就认为可弹出。这个判断可靠得多。

6.3 MSVC 与 MinGW 下的工程配置差异

Qt 工程里加这些 Win32 依赖，不同编译器配置不一样。

MSVC 下用#pragma comment(lib, "setupapi.lib")就能搞定，写在头文件里最省事。MinGW 下.pro文件里加：

win32-g++ { LIBS += -lsetupapi -lcfgmgr32 }

CMake 的话统一用target_link_libraries：

if (WIN32) target_link_libraries(${PROJECT_NAME} PRIVATE setupapi cfgmgr32) endif()

还有一个容易漏的地方：GUID_DEVINTERFACE_DISK这个 GUID 定义在devguid.h里，而devguid.h在某些 SDK 版本里需要先包含initguid.h才能拿到实际定义，否则报 undefined reference。我遇到过在某个较老的 SDK 上是这个情况，加上#include <initguid.h>之后就好了。

MinGW 的另一个坑是PSP_DEVICE_INTERFACE_DETAIL_DATA_W的cbSize字段，32 位和 64 位下结构体对齐不同，必须用sizeof宏赋值，硬编码成 6 或者 8 在另一种位宽下必崩。这个坑网上流传的示例代码里到处都是，抄的时候一定要注意。

6.4 一个值得单独说的稳定性细节

最后分享一个我在长时间运行测试里才发现的问题。上位机连续跑了三天，弹出功能在第二天开始出现偶发失败，重启程序就好了。查下来是句柄泄漏。

SetupDiGetClassDevsW返回的HDEVINFO如果不调SetupDiDestroyDeviceInfoList就会泄漏，这个我一开始注意到了。但我漏掉了另一处：循环里SetupDiGetDeviceInterfaceDetailW第二次调用失败时，我用continue跳过了后续逻辑，而那个已经从第一次调用里分配出去的SP_DEVINFO_DATA里可能持有内部引用。虽然文档上没说需要显式释放，但实际测试中大量失败重试之后句柄数确实涨。

我的改法是：每次循环结束时无条件执行清理路径，把HANDLE的关闭、QByteArray的析构统一放到一个小的 RAII 结构里，用goto cleanup或者 lambda 保证所有出口都走同一段收尾代码。改完之后跑了五天没有复现。

提示：这类设备枚举代码的泄漏在短时间测试里完全看不出来，必须做长时间循环压测。我的做法是写一个只调枚举不调弹出的循环，跑十万次看句柄数和私有内存的增长曲线。

这套代码后来被我封装成了一个独立的WinDeviceManager模块，光驱和 U 盘两条路径共用同一套句柄管理，错误码映射也统一了。再遇到类似需求，只要把盘符喂进去，剩下的判断、线程、超时全部走既定流程，不用再重新推一遍设备树。设备管理这块最省时间的做法就是别信第一次跑通的代码，多插拔几十次，多换几台机器，很多问题只在特定主控和特定过滤驱动组合下才冒出来。