createnamedpipe是windows创建命名管道服务器端实例的核心api，返回句柄或invalid_handle_value；需正确配置dwopenmode（如pipe_access_duplex）、dwpipemode（如pipe_type_message）、nmaxinstances等参数，否则易致error_pipe_busy或访问拒绝。

Windows上用CreateNamedPipe创建服务端管道

命名管道在Windows上是内核对象，服务端必须先创建才能被客户端连接。关键不是“怎么建”，而是“建对参数”——CreateNamedPipe 的第4个参数（dwOpenMode）和第7个（dwMaxInstances）最容易出错。

常见错误现象：ConnectNamedPipe 返回 FALSE，GetLastError() 是 ERROR_PIPE_BUSY，但没调用 WaitNamedPipe 就直接重试；或者设了 PIPE_UNLIMITED_INSTANCES 却忘了服务端需循环调用 CreateNamedPipe 重建新实例。

• dwOpenMode 至少要含 PIPE_ACCESS_DUPLEX（双向）或 PIPE_ACCESS_INBOUND（单向入），否则客户端 CreateFile 会报 ERROR_ACCESS_DENIED
• 务必设 SECURITY_DESCRIPTOR（哪怕只允许本用户访问），否则默认安全描述符可能拒绝本地非管理员连接
• 调用 ConnectNamedPipe 前，确保管道句柄处于非阻塞等待状态——它本身是同步阻塞的，但若传入已连接句柄会立即失败

客户端用CreateFile连接命名管道

客户端不创建管道，只用 CreateFile 打开已存在的管道名。路径格式固定为 \\.\pipe\{name}，漏掉任意一个反斜杠或大小写错误都会导致 ERROR_FILE_NOT_FOUND。

使用场景：客户端启动快于服务端时，不能直接硬连。必须先用 WaitNamedPipe 等待服务端就绪，否则 CreateFile 立即失败。

• dwDesiredAccess 必须与服务端 dwOpenMode 兼容：比如服务端开 PIPE_ACCESS_DUPLEX，客户端就得用 GENERIC_READ | GENERIC_WRITE
• 超时控制靠 WaitNamedPipe 的 nTimeOut 参数，设成 0 表示不等，设成 INFINITE 会永久挂起（不推荐）
• 如果服务端支持多实例，客户端每次 CreateFile 都会拿到独立句柄，无需额外同步

读写时用ReadFile/WriteFile而非标准IO函数

命名管道句柄是 Windows 句柄，不是 C 运行时文件流，不能用 fread/fwrite 或 std::ifstream。必须用 ReadFile 和 WriteFile，且要注意它们的缓冲区语义与 socket 不同。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

性能影响：管道默认启用缓冲（PIPE_TYPE_MESSAGE 模式下按消息边界读），但若服务端创建时用的是 PIPE_TYPE_BYTE，ReadFile 可能只返回部分数据，必须检查返回字节数并循环读取。

• 调用 ReadFile 前，确保 lpNumberOfBytesRead 指针有效，否则崩溃
• 异步读写需传入 OVERLAPPED 结构，并用 GetOverlappedResult 或 I/O 完成端口获取结果——同步模式更简单，但会阻塞线程
• 关闭句柄前，建议先调用 FlushFileBuffers，避免内核缓冲区残留未发送数据

Linux不支持原生命名管道IPC？用FIFO+信号量模拟

C++ 标准库没有跨平台命名管道抽象，Linux 的 mkfifo 创建的是 POSIX FIFO，它本质是文件系统节点，不具备 Windows 命名管道的客户端/服务端角色分离、多实例、消息边界等特性。

容易被忽略的地方：FIFO 是单向的，一端 open(O_WRONLY) 阻塞直到另一端 open(O_RDONLY)，若顺序不对会死锁；且没有内置的访问控制或超时机制。

• 必须用 open + read/write 系统调用，不能用 std::fstream 直接打开（除非先 fdopen 转换）
• 需自行用 sem_open 或 pthread_mutex_t 同步读写，否则多个客户端同时写会导致数据交错
• 服务端无法感知客户端断连（不像 Windows 管道有 DisconnectNamedPipe），只能靠读返回 0 字节判断对方关闭

跨平台 IPC 最难的不是语法，是语义对齐：Windows 管道的消息模式、连接生命周期、错误码含义，和 Linux FIFO 的字节流、无状态、信号驱动，根本不在同一抽象层。硬封装一层“NamedPipe”类，反而会让边界错误更隐蔽。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！