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 立即失败。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
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 不同。
性能影响：管道默认启用缓冲（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”类，反而会让边界错误更隐蔽。
