咱来拆解下你遇到的这个问题——明明给CreateFile加了FILE_FLAG_OVERLAPPED开启异步IO，循环调用WriteFile时却还是阻塞，大概率是以下几个常见的坑没踩对：

1. OVERLAPPED结构体初始化不规范 #

这是异步IO最容易踩的坑之一：

• 如果你在循环中复用同一个OVERLAPPED结构体，却没有每次重置它的状态，比如没有调用ResetEvent(ov.hEvent)，或者没有重新初始化Offset/OffsetHigh字段，系统会认为前一次的IO操作还在进行，导致WriteFile阻塞等待。
• 正确的做法是，要么每次循环都重新创建并初始化OVERLAPPED：

  for (int i = 0; i < 100; ++i) {
      OVERLAPPED ov{}; // 零初始化
      ov.hEvent = CreateEvent(nullptr, TRUE, FALSE, nullptr); // 创建手动重置事件
      ov.Offset = static_cast<DWORD>(i * bufferSize);
      ov.OffsetHigh = static_cast<DWORD>((i * bufferSize) >> 32);
      // 调用WriteFile...
      // 记得后续关闭事件句柄
  }
  

  要么复用事件时，每次调用前重置事件状态：

  ResetEvent(ov.hEvent);
  

2. CreateFile参数存在遗漏或错误 #

• 首先要确认你确实在CreateFile的dwFlagsAndAttributes参数中传入了FILE_FLAG_OVERLAPPED，如果漏传了，文件会以同步模式打开，WriteFile自然会阻塞。
• 另外，使用异步IO时，系统不会维护文件指针，所以每次WriteFile必须在OVERLAPPED的Offset和OffsetHigh字段指定写入位置。如果多次调用都使用相同的偏移，可能会触发IO冲突，导致系统同步等待之前的IO完成。

3. 文件系统或设备不支持异步IO #

有些文件系统（比如FAT32）或者老旧的存储设备可能不支持异步IO，即使你设置了FILE_FLAG_OVERLAPPED，系统也会自动退化为同步IO模式，导致WriteFile阻塞。你可以把测试文件放到NTFS分区上再试试。

4. 错误处理逻辑缺失 #

你可以在每次调用WriteFile后，检查返回值和错误码，确认是否真的进入了异步模式：

BOOL writeResult = WriteFile(hFile, buffer, bufferLen, nullptr, &ov);
DWORD lastErr = GetLastError();
if (!writeResult) {
    if (lastErr == ERROR_IO_PENDING) {
        // 这才是真正的异步操作，不会阻塞
        // 你可以在这里继续执行其他任务，之后再通过事件或IOCP等待完成
    } else {
        // 其他错误，比如文件句柄无效、权限不足等，需要排查
    }
} else {
    // 操作同步完成了，说明IO立即执行完毕，也不会阻塞
}

如果WriteFile直接返回TRUE，说明操作同步完成了，这不是阻塞，而是IO本身就很快完成了；如果返回FALSE且错误码不是ERROR_IO_PENDING，那就是真的出问题了，得先解决这些错误。

额外检查点 #

• 确认CreateFile返回的文件句柄不是INVALID_HANDLE_VALUE，如果句柄无效，后续的WriteFile行为是未定义的，可能会出现阻塞或其他异常。
• 如果你在调用WriteFile后立即调用了WaitForSingleObject(ov.hEvent, INFINITE)或者GetOverlappedResult(hFile, &ov, &bytesWritten, TRUE)，那阻塞是你主动等待IO完成导致的，这属于正常逻辑，不是异步IO的问题。

内容的提问来源于stack exchange，提问作者tcb