为何回调已报告字节全复制完成，CopyFileEx仍处于阻塞状态？

核心原因 #

你猜的没错，延迟确实来自磁盘缓存刷新或文件系统收尾操作——CopyFileEx在回调报告字节传输完成后，还需要完成文件元数据写入、缓存刷盘、文件句柄清理等后台工作，HDD的低速放大了这个过程的感知延迟。COPY_FILE_NO_BUFFERING没解决问题，是因为它只跳过了数据缓存，无法规避元数据写入、文件系统同步这些收尾步骤。

可行解决办法 #

1. 手动实现文件复制流程，主动控制收尾操作

放弃CopyFileEx，自己封装文件复制逻辑：

• 用CreateFile分别打开源文件（只读）和目标文件（写入、创建），如果要跳过缓存，目标文件可以带FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH标志（注意对齐读写大小到扇区）。
• 用ReadFile/WriteFile分块读写数据，实时更新进度条。
• 当最后一块数据写入完成后，主动调用FlushFileBuffers刷新目标文件，同时在UI上显示“正在完成磁盘写入...”的状态，直到刷新完成后再关闭文件句柄。
• 这种方式能把收尾阶段的延迟暴露给用户，避免进度条卡在100%却无反馈的情况，同时完全掌控复制流程。

2. 后台线程+UI状态优化

如果不想放弃CopyFileEx，重点优化用户感知：

• 把CopyFileEx的调用放到独立的后台工作线程，不要阻塞UI线程。
• 回调函数只负责向UI线程发送进度更新消息，当回调报告字节传输完成时，UI立刻切换状态（比如进度条保持100%，但显示“正在收尾，请稍候...”），同时保持界面可响应（比如允许窗口操作）。
• 直到CopyFileEx真正返回后，再启动下一个文件的复制。这种方法不解决延迟，但能消除“无响应”的糟糕体验。

3. 临时调整目标磁盘的写入策略（需管理员权限）

通过DeviceIoControl调用FSCTL_SET_WRITE_THROUGH，将目标磁盘设置为直写模式，让写入操作直接落地磁盘，减少缓存堆积带来的收尾延迟。操作完成后记得恢复原策略，避免影响其他磁盘操作的性能。示例代码片段：

HANDLE hVolume = CreateFile(L"\\\\.\\D:", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
if (hVolume != INVALID_HANDLE_VALUE) {
    BOOL bWriteThrough = TRUE;
    DWORD bytesReturned;
    DeviceIoControl(hVolume, FSCTL_SET_WRITE_THROUGH, &bWriteThrough, sizeof(bWriteThrough), NULL, 0, &bytesReturned, NULL);
    CloseHandle(hVolume);
}

注意：这个方法比较激进，只适合批量大文件复制场景，日常使用不建议。

4. 尝试COPY_FILE_RESTARTABLE标志

添加COPY_FILE_RESTARTABLE标志调用CopyFileEx，它会让系统在复制过程中生成临时的断点续传文件，可能改变内部的缓存和同步逻辑，部分场景下能减少收尾延迟。不过这个效果依赖系统版本和文件系统，需要实际测试验证。

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