最常见原因是路径字符串未正确处理：Windows API 不接受正斜杠，需用双反斜杠和宽字符（L"..."），并统一调用 CreateFileW；错误码需用 GetLastError() 检查，如 ERROR_PATH_NOT_FOUND 或 ERROR_ACCESS_DENIED。
为什么 CreateFile 打开文件总是返回 INVALID_HANDLE_VALUE
最常见原因是路径字符串没处理好——Windows API 默认不接受正斜杠 /，也不自动补全当前目录，且 Unicode 路径必须用宽字符（L"..."）传入。如果用窄字符串（"..."）调用 CreateFileA，而路径含中文或特殊符号，大概率失败；若调用 CreateFileW 却传 char*，会把字节当 wchar_t 解释，直接越界。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 统一用
CreateFileW，路径写成L"C:\temp\data.bin"—— 反斜杠双写，开头加L - 避免拼接路径：不要用
std::string+.c_str()传给CreateFileW；改用std::wstring或std::filesystem::path的c_str() - 检查错误码：调用后立刻
GetLastError()，常见值如ERROR_PATH_NOT_FOUND（目录不存在）、ERROR_ACCESS_DENIED（权限不足，尤其系统目录或正在被其他进程占用）
CreateFile 的 dwCreationDisposition 参数怎么选才不丢数据
这个参数决定文件不存在时是否创建、存在时是否清空，选错会导致覆盖或写入失败。比如想追加日志却用了 CREATE_ALWAYS，每次打开都清空旧内容；想读配置却用了 OPEN_ALWAYS，文件不存在时会新建一个空文件，掩盖了“配置缺失”的问题。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 只读场景：用
OPEN_EXISTING—— 文件必须存在，否则失败，适合配置文件、资源加载 - 写新文件（不覆盖）：用
CREATE_NEW—— 文件已存在则失败，避免误覆盖 - 覆盖写：用
CREATE_ALWAYS—— 总是清空重来，适合缓存、临时输出 - 追加写：先用
OPEN_EXISTING打开，再用SetFilePointer移到末尾，最后WriteFile；别依赖FILE_APPEND_DATA权限自动定位——它只保证写入位置在末尾，但并发写时仍可能冲突
用 CreateFile 读写二进制文件时，ReadFile/WriteFile 返回值为 0 却没报错
这通常不是函数失败，而是同步 I/O 在文件末尾或缓冲区空时的正常行为。但更隐蔽的问题是：你传给 ReadFile 的缓冲区地址非法、大小为 0，或句柄没开对读/写权限（比如用 GENERIC_READ 打开却调 WriteFile），此时函数直接返回 FALSE，但 GetLastError() 可能还是 0（未设置），容易误判。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 检查句柄权限：打开时指定的
dwDesiredAccess必须包含对应操作权限，GENERIC_READ | GENERIC_WRITE不等于“啥都能干”，得看实际需要 - 确认缓冲区有效：
lpBuffer不能是栈上即将销毁的局部数组（比如函数返回后指针悬空），大小不能为 0 - 同步读写必须检查返回值：
ReadFile返回TRUE才代表成功，FALSE时必须调GetLastError()；即使返回TRUE，也要看lpNumberOfBytesRead是否等于预期——读到 EOF 时它可能小于请求长度
用 CreateFile 打开串口或命名管道时，为什么超时设置不起作用
因为 CreateFile 本身不控制 I/O 超时，它只负责打开设备。串口和管道的读写超时由后续的 SetCommTimeouts（串口）或 SetNamedPipeHandleState（管道）控制。如果跳过这步，ReadFile 可能永远阻塞，哪怕你设置了 FILE_FLAG_OVERLAPPED，异步操作也需配套的事件/完成端口机制才能响应超时。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 串口：打开后立即调
SetCommTimeouts，填COMMTIMEOUTS结构体，重点设ReadTotalTimeoutConstant - 命名管道：用
CreateFile打开客户端句柄后，服务端需用ConnectNamedPipe，并在之前用SetNamedPipeHandleState设置PIPE_WAIT和超时 - 别混淆标志位：
FILE_FLAG_OVERLAPPED是启用异步 I/O 的前提，但不等于“自动超时”；没配超时参数的异步读写，照样可能卡在GetOverlappedResult等待中
