createnamedpipe 关键参数需匹配：pipe_access_duplex 必须配 pipe_type_message 或 pipe_type_byte；nmaxinstances 建议设具体值（如10）而非 pipe_unlimited_instances；dwpipemode 影响消息边界，ipc 场景优先选消息模式。
创建命名管道时 CreateNamedPipe 的关键参数怎么选
Windows 命名管道不是“建了就能连”，CreateNamedPipe 的参数稍有偏差，客户端一调 ConnectNamedPipe 就阻塞或立刻失败。最常踩的坑是 dwOpenMode 和 dwPipeMode 搭配错。
-
PIPE_ACCESS_DUPLEX必须和PIPE_TYPE_MESSAGE或PIPE_TYPE_BYTE配合使用；若只写PIPE_ACCESS_INBOUND，客户端就只能单向写，服务端读完一次就断 - 消息模式（
PIPE_TYPE_MESSAGE）下，每次WriteFile是一个完整消息，ReadFile也必须按消息边界读；字节模式（PIPE_TYPE_BYTE）则像流，不保消息边界——但多数 IPC 场景建议用消息模式，避免粘包 -
nMaxInstances设为PIPE_UNLIMITED_INSTANCES看似省事，实际会因句柄泄漏或未清理实例导致后续创建失败，建议设具体值（如10）
ConnectNamedPipe 为什么总卡住或返回 ERROR_PIPE_CONNECTED
这不是错误，是正常状态——说明客户端已连上，但你没处理好同步逻辑。常见现象：服务端调完 ConnectNamedPipe 后程序停住、CPU 降为 0，或者刚连上就报错断开。
- 同步模式下，
ConnectNamedPipe会阻塞直到客户端调CreateFile；若客户端还没启动，服务端就卡死——必须用超时（SetEvent+WaitForSingleObject）或改异步 I/O - 返回
ERROR_PIPE_CONNECTED表示连接已在上次调用中建立（比如重连），此时不该再调一次ConnectNamedPipe，直接读写即可 - 每次连接处理完，务必调
DisconnectNamedPipe再调CloseHandle；漏掉DisconnectNamedPipe会导致下一次CreateNamedPipe失败（ERROR_ACCESS_DENIED）
客户端用 CreateFile 连接失败的典型原因
客户端连不上，90% 出在路径、权限或时机。错误信息往往是 ERROR_FILE_NOT_FOUND 或 ERROR_ACCESS_DENIED，但真正原因和字面意思常不一致。
- 管道名格式必须是
\\.\pipe\xxx，少一个反斜杠或大小写错误（如PIPE写成pipe）都会报ERROR_FILE_NOT_FOUND - 服务端还没调
ConnectNamedPipe（或已断开），客户端就急着CreateFile，会返回ERROR_PIPE_BUSY——应循环重试，配合WaitNamedPipe - 跨用户会话（比如服务跑在 Session 0，GUI 客户端在 Session 1）默认无法访问；需在
CreateNamedPipe中加SECURITY_DESCRIPTOR并设置SE_GROUP_DEFAULT权限，否则就是ERROR_ACCESS_DENIED
消息收发时 ReadFile/WriteFile 返回 0 字节或失败
不是数据丢了，是管道状态或缓冲区没对齐。尤其在消息模式下，读写行为和文件完全不同。
- 消息模式中，
ReadFile若传入缓冲区太小（小于消息实际长度），会返回FALSE且GetLastError()是ERROR_MORE_DATA——必须按提示扩大缓冲区重读，不能忽略 - 写入前确认管道是否仍处于连接状态：
GetNamedPipeInfo查lpState是否为PIPE_CONNECTED；否则WriteFile可能返回 0 字节并设ERROR_BROKEN_PIPE - 不要混用同步/异步句柄：服务端用
FILE_FLAG_OVERLAPPED创建，客户端却用普通CreateFile，会导致读写行为不可预测
命名管道真正的复杂点不在 API 调用顺序，而在状态机管理——连接、读、写、断开每个环节都可能中途失效，且错误码含义高度依赖上下文。别指望一次写对，先用 GetLastError 把每次失败的具体码打出来，比查文档快得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
