ReadDirectoryChangesW比轮询高效因其为内核级异步通知机制，目录变动时系统直接写入缓冲区，避免反复调用查询API；但需手动管理重叠I/O、缓冲区生命周期及FILE_NOTIFY_INFORMATION解析，必须异步使用并严防事件丢失或崩溃。
ReadDirectoryChangesW 为什么比轮询高效
因为它是内核级异步通知机制，目录有变动时系统直接往你提供的缓冲区写入变更记录，不用你反复调用 FindFirstFile 或 GetFileAttributes 去查。但代价是：你得自己管理重叠 I/O、缓冲区生命周期和事件解析逻辑——稍不注意就丢事件或崩溃。
必须用 OVERLAPPED + 异步模式，不能同步等
同步调用 ReadDirectoryChangesW 会阻塞线程，且容易漏掉高频连续变更（比如 IDE 保存文件时触发的重命名+写入+属性修改）。实际生产中只应使用异步方式：
- 分配一个长期有效的
OVERLAPPED结构，hEvent字段设为NULL（避免意外触发事件对象） - 调用前确保缓冲区（如
std::vector<byte> buffer(64 * 1024)</byte>）在整个监控周期内有效，不能是栈变量或短命临时对象 - 调用返回
FALSE且GetLastError() == ERROR_IO_PENDING才算真正启动成功；否则说明参数错或权限不足（比如监控网络路径但没开 SMB 签名）
FILE_NOTIFY_INFORMATION 解析容易踩的坑
返回的原始数据是变长结构链表，每个节点以 NextEntryOffset 链接下一个——不是数组，不能用下标遍历。常见错误包括：
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 把
FileNameLength当作字节数用，其实单位是WCHAR，要乘以sizeof(WCHAR)才能正确截取字符串 - 忽略
NextEntryOffset == 0是链表结尾标志，导致越界读内存（尤其在缓冲区满、最后一个节点被截断时） - 没检查
Action值范围（合法值是 1–6），某些旧驱动可能返回 0 或其他非法值，直接switch会跳进默认分支甚至崩溃
示例关键片段：
auto* info = reinterpret_cast<FILE_NOTIFY_INFORMATION*>(buffer.data());
do {
std::wstring name(info->FileName, info->FileNameLength / sizeof(WCHAR));
switch (info->Action) {
case FILE_ACTION_ADDED: /* ... */ break;
case FILE_ACTION_MODIFIED: /* ... */ break;
// 其他 case
}
if (info->NextEntryOffset == 0) break;
info = reinterpret_cast<FILE_NOTIFY_INFORMATION*>(
reinterpret_cast<BYTE*>(info) + info->NextEntryOffset
);
} while (true);
缓冲区大小和重新投递时机决定是否丢事件
64KB 缓冲区在多数场景够用，但遇到批量操作（如 git checkout、解压大 ZIP）仍可能溢出。此时 ReadDirectoryChangesW 返回 FALSE 且 GetLastError() == ERROR_NOTIFY_ENUM_DIR，表示内核丢弃了部分事件并清空队列——你无法恢复丢失项，只能记录告警并立即重新投递新请求。
立即学习“C++免费学习笔记（深入）”；
- 每次完成一次异步操作（不管成功或失败），都必须立刻再次调用
ReadDirectoryChangesW投递下一轮监听，否则监控就中断了 - 不要在回调里直接处理耗时操作（如读文件内容、发网络请求），应把
FILE_NOTIFY_INFORMATION拷贝出来后交由工作线程处理，避免阻塞 I/O 线程导致后续事件积压 - 监控子目录需显式设置
FILE_NOTIFY_CHANGE_DIR_NAME，仅设FILE_NOTIFY_CHANGE_FILE_NAME不会收到子目录下的变动
最常被忽略的是：同一个句柄上不能并发多次未完成的 ReadDirectoryChangesW 调用，否则行为未定义。必须严格“完成一个 → 投递一个”，靠 GetOverlappedResult 或 I/O 完成端口来串行化流程。
