Windows命名管道性能瓶颈在于默认PIPE_WAIT模式、小数据块同步I/O及未启用重叠I/O，导致内核态频繁切换；需用PIPE_TYPE_MESSAGE+PIPE_READMODE_MESSAGE配异步I/O，并避免句柄泄漏与命名错误。
命名管道在 Windows 下的性能瓶颈在哪
Windows 命名管道（CreateNamedPipe）本身不是“慢”，但默认配置下极易退化成同步阻塞 I/O，导致吞吐卡在几 MB/s 甚至更低。真正拖慢的是 PIPE_WAIT 模式 + 单次 ReadFile/WriteFile 小数据块 + 无重叠 I/O，这会让每次通信都陷进内核态切换和上下文抖动。
- 必须用
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE配合PIPE_WAIT或PIPE_NOWAIT—— 否则消息边界丢失，接收端要自己拼包 - 服务端调用
CreateNamedPipe时，nMaxInstances别设成PIPE_UNLIMITED_INSTANCES：超过 256 实例会触发内核资源碎片，连接建立延迟陡增 - 客户端
CreateFile打开管道时，dwFlagsAndAttributes至少带FILE_FLAG_OVERLAPPED，否则后续无法用ReadFileEx/WriteFileEx异步收发
怎么写一个不丢消息、不卡死的异步读循环
核心是避免轮询和阻塞等待，用 OVERLAPPED + I/O 完成例程（或 I/O CP），而不是 WaitForSingleObject 死等事件。常见错误是把 GetOverlappedResult 放在循环里反复调，它本质仍是同步等待。
- 为每个连接分配独立的
OVERLAPPED结构体，且确保其生命周期长于 I/O 请求（不能在栈上临时声明后传入） - 调用
ReadFile前，先 memsetOVERLAPPED，并设置hEvent = NULL；若用完成端口，则忽略hEvent，靠PostQueuedCompletionStatus触发回调 - 收到
ERROR_IO_PENDING是正常路径，不是错误；收到ERROR_MORE_DATA表示消息未读完，需继续ReadFile直到返回实际字节数或ERROR_PIPE_EMPTY - 示例关键片段：
DWORD dwRead; BOOL bRet = ReadFile(hPipe, buf, sizeof(buf), &dwRead, &ol); if (!bRet && GetLastError() == ERROR_IO_PENDING) { // 进入异步等待，不阻塞 }
为什么 PIPE_TYPE_BYTE 在高吞吐场景下很危险
它让管道退化成字节流，发送端写 3 次 1KB，接收端可能一次读出 3KB、也可能分 5 次读出——你得自己维护缓冲区、解析长度头、处理粘包/半包。而 PIPE_TYPE_MESSAGE 由系统保证单次 WriteFile 对应单次 ReadFile，哪怕写入 10MB，只要没超 nOutBufferSize，读端一次就能拿到完整消息。
-
PIPE_READMODE_MESSAGE必须和服务端CreateNamedPipe的dwOpenMode中的PIPE_TYPE_MESSAGE匹配，否则SetNamedPipeHandleState会失败 - 消息最大尺寸受服务端创建时
nOutBufferSize和nInBufferSize限制，默认 64KB；若需传输更大消息，必须显式增大这两个值，否则WriteFile直接返回ERROR_NOT_ENOUGH_MEMORY - 不要在消息体里嵌套 NUL 字符（
PIPE_TYPE_MESSAGE模式下系统不按 C 字符串处理，但某些封装层（如 Qt 的QProcess）会误截断
跨进程通信时句柄泄漏和连接僵死怎么防
Windows 命名管道的句柄不像 socket 那样有清晰的“断连通知”。客户端进程崩溃、强制关机、网络中断（对本地命名管道少见但可能发生在远程管道）都会让服务端一直挂着无效句柄，最终耗尽 MAXIMUM_WAIT_OBJECTS 或句柄表。
立即学习“C++免费学习笔记（深入）”；
- 服务端每次
ConnectNamedPipe成功后，立即调用SetTimer或启动单独线程，用WaitNamedPipe定期探测客户端是否还活着（例如每 5 秒一次，超时 1 秒） - 调用
DisconnectNamedPipe前，先FlushFileBuffers，否则最后一点数据可能滞留在内核缓冲区没发出 - 客户端退出前务必调用
CloseHandle；若异常退出，服务端可通过GetNamedPipeInfo检查lpMaxCollectionCount是否为 0（表示对方已断开），但这不是实时的，只能作为辅助判断 - 别依赖
WaitForMultipleObjects等待大量管道句柄：Windows 对可等待对象数量有限制（默认 64），超过要用 I/O 完成端口（CreateIoCompletionPort）
最易被忽略的一点：命名管道的名称空间不是全局的。\.pipemyapp 和 \serverpipemyapp 是两回事；本地通信必须用 \.pipe... 前缀，写成 \localhostpipe... 会走 SMB 协议栈，性能掉一个数量级。还有，管道名区分大小写，但 Windows API 不校验，拼错只会默默创建新管道。
