直接读取Windows NTFS卷的MFT在用户态不可行，因NTFS驱动内核层强制拦截元数据I/O请求；替代方案是使用FSCTL_ENUM_USN_DATA读取USN日志，它支持实时、增量、带路径的文件变更监控。
为什么直接读 MFT 在 Windows 上几乎不可行
Windows 不允许用户态程序直接读取 NTFS 卷的主文件表（MFT），哪怕你有管理员权限。\.C: 这类物理卷句柄打开后调用 ReadFile 去读 MFT 起始扇区，会立刻触发 STATUS_ACCESS_DENIED 或 STATUS_INVALID_DEVICE_REQUEST。NTFS 驱动在内核层拦截了对元数据区域（包括 $MFT、$Bitmap、$LogFile）的直接 I/O 请求——这不是权限问题，是驱动强制策略。
常见误操作包括：
- 用
CreateFile打开\\.\C:后跳过SetFilePointerEx直接读，结果返回 0 字节且GetLastError()是 5（ACCESS_DENIED） - 尝试用
DeviceIoControl发送FSCTL_READ_MFT_RECORD（该 IOCTL 根本未公开，也不存在于 winioctl.h 中） - 依赖某些“NTFS 解析库”声称能“离线解析 MFT”，但实际只适用于已导出的原始镜像（如 dd 出来的 .img），不适用于实时挂载卷
真正可用的替代路径：FSCTL_ENUM_USN_DATA
Windows 提供了受支持、高性能、能反映实时文件变更的机制：FSCTL_ENUM_USN_DATA。它不读 MFT，而是读 USN 日志（更新序列号日志），该日志由 NTFS 自动维护，记录所有文件/目录的创建、修改、重命名、删除等事件。它的优势是：
- 用户态可调用，只需卷句柄 +
FILE_TRAVERSE权限（普通管理员即可） - 响应极快：一次调用可批量获取数千条记录，支持增量枚举（靠
USN值续传） - 天然带路径名（
FileNameOffset+FileNameLength指向缓冲区内存）
关键实操点：
立即学习“C++免费学习笔记（深入）”；
- 必须先用
GetVolumeInformationByHandleW确认卷支持 USN 日志（FILE_SUPPORTS_USN_JOURNAL） - 首次调用需传入
STARTING_USN为 0，后续用上一次返回的NextUsn续查 -
USN_JOURNAL_DATA结构体中的FileName是 UTF-16 小端，无 null 终止符，需按FileNameLength截取 - 过滤掉
USN_REASON_CLOSE和USN_REASON_SECURITY_CHANGE等无关事件，聚焦USN_REASON_FILE_CREATE/USN_REASON_RENAME_NEW_NAME
如何用 C++ 快速构建一个基于 USN 的文件名搜索索引
不要试图在每次搜索时遍历全量 USN 日志——那是 O(n) 且延迟不可控。正确做法是启动一个后台线程持续监听 USN 变更，并构建内存中倒排索引（例如 std::unordered_map<:wstring std::vector>></:wstring>，键为小写文件名，值为完整路径列表）。
核心逻辑片段（省略错误检查）：
HANDLE hVol = CreateFile(L"\\.\C:", GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE,
nullptr, OPEN_EXISTING, 0, nullptr);
USN_JOURNAL_DATA journal;
DWORD bytes;
DeviceIoControl(hVol, FSCTL_QUERY_USN_JOURNAL, nullptr, 0, &journal, sizeof(journal), &bytes, nullptr);
<p>USN startUsn = journal.FirstUsn;
while (true) {
char buf[64 <em> 1024];
READ_USN_JOURNAL_DATA readData = {startUsn, 0, TRUE, 0, 0, 0};
if (DeviceIoControl(hVol, FSCTL_READ_USN_JOURNAL, &readData, sizeof(readData),
buf, sizeof(buf), &bytes, nullptr)) {
PUSN_RECORD record = (PUSN_RECORD)(buf + sizeof(USN));
while ((char</em>)record < buf + bytes) {
if (record->Reason & (USN_REASON_FILE_CREATE | USN_REASON_RENAME_NEW_NAME)) {
std::wstring name(record->FileName, record->FileNameLength / sizeof(wchar_t));
std::wstring path = GetParentPathFromUsnRecord(record); // 需自行实现：通过 record->FileReference 获取父目录路径
index[toLower(name)].push_back(path + L'' + name);
}
record = (PUSN_RECORD)((char<em>)record + record->RecordLength);
}
startUsn = </em>(USN<em>)((char</em>)buf + sizeof(USN)); // NextUsn at start of buffer
}
Sleep(1000);
}</p>注意：GetParentPathFromUsnRecord 并非系统 API，需结合 FSCTL_GET_RETRIEVAL_POINTERS 或缓存目录树结构来实现；真实项目中建议用 FindFirstFileTransacted 回滚补全缺失路径。
性能瓶颈和绕不过去的现实约束
USN 方案虽快，但仍有硬性限制：
- USN 日志默认大小约 32MB，满后旧记录被覆盖——无法回溯超过日志窗口期的历史文件（可通过
FSCTL_CREATE_USN_JOURNAL扩容，但需管理员权限且影响磁盘空间） - 重命名/移动文件时，
USN_REASON_RENAME_OLD_NAME和USN_REASON_RENAME_NEW_NAME是两条独立记录，需配对处理才能维持路径一致性 - NTFS 压缩、稀疏文件、重解析点（符号链接）的路径解析必须额外调用
GetFinalPathNameByHandle，否则拿到的是重解析前路径 - 搜索“*.log”这类通配符时，仍需遍历内存索引的 key 集合做字符串匹配——不如 SQLite FTS 加速，但比
FindFirstFile全盘扫描快两个数量级
最常被忽略的一点：USN 日志不记录文件内容哈希或大小，仅含路径与时间戳。如果搜索需求依赖内容特征（比如“找出所有包含 ‘API_KEY’ 的 .env 文件”），就必须配合内存映射 + 正则扫描，此时性能拐点就落在 I/O 调度而非索引结构上了。
