命名管道服务端必须先调用CreateNamedPipe创建实例，再立即调用ConnectNamedPipe（阻塞）或配合OVERLAPPED结构等待客户端连接，否则ReadFile会返回ERROR_PIPE_NOT_CONNECTED；客户端CreateFile本质是连接请求，超时和权限设置不当会导致ERROR_TIMEOUT、ERROR_PIPE_BUSY或ERROR_ACCESS_DENIED；消息模式下需严格匹配PIPE_TYPE_MESSAGE与PIPE_READMODE_MESSAGE，单条消息不超过64KB；服务端处理完连接须先DisconnectNamedPipe再CloseHandle，否则引发句柄泄漏。
命名管道服务端必须先创建，且 CreateNamedPipe 返回句柄才可接受连接
很多初学者卡在“客户端连不上”，根本原因是服务端没真正启动监听。调用 CreateNamedPipe 只是创建了一个未连接的管道实例，必须紧接着用 ConnectNamedPipe（阻塞）或配合 OVERLAPPED（异步）等待客户端连接。若跳过这步直接读写，GetLastError() 通常返回 ERROR_PIPE_NOT_CONNECTED。
常见错误写法：
HANDLE hPipe = CreateNamedPipe(L"\\.\pipe\MyPipe", ...);<br>// 忘了调用 ConnectNamedPipe，就去 ReadFile —— 必然失败
- 服务端需循环调用
ConnectNamedPipe（每次连接后需重新调用，除非设为PIPE_UNLIMITED_INSTANCES） - 若使用
FILE_FLAG_OVERLAPPED，必须提供有效的OVERLAPPED结构，且不能在未完成前重复传入同一变量 - 推荐用
WaitForMultipleObjects管理多个重叠操作，避免单线程阻塞
客户端用 CreateFile 连接时，超时和权限是两大隐形杀手
CreateFile 打开命名管道不是普通文件操作：它本质是发起连接请求。若服务端尚未调用 ConnectNamedPipe，默认行为是阻塞最长 50 毫秒（取决于 dwOpenMode 中是否含 FILE_FLAG_OVERLAPPED），然后失败并返回 ERROR_TIMEOUT 或 ERROR_PIPE_BUSY。
- 加
FILE_FLAG_OVERLAPPED后，CreateFile立即返回，但需用GetOverlappedResult或WaitForSingleObject等待连接完成 - Windows 默认禁止跨用户访问命名管道，服务端创建时若没显式设置
SECURITY_DESCRIPTOR，非 SYSTEM 或同用户客户端会收到ERROR_ACCESS_DENIED - 测试阶段可临时用
ConvertStringSecurityDescriptorToSecurityDescriptor加上"D:P(A;;GA;;;WD)"（允许所有人）验证逻辑，上线前务必收紧权限
读写必须匹配模式，PIPE_TYPE_MESSAGE 下 WriteFile 一次写入 = 一次 ReadFile 接收
命名管道有字节模式（PIPE_TYPE_BYTE）和消息模式（PIPE_TYPE_MESSAGE）之分。后者更常用，但新手常忽略其“原子性”语义：哪怕你分多次 WriteFile，只要没关管道，服务端一次 ReadFile 就可能把所有缓冲数据全读出来——除非服务端也用 PIPE_READMODE_MESSAGE，此时每次 ReadFile 严格对应客户端一次 WriteFile 的完整内容。
- 服务端创建时指定
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE，客户端写入必须小于 64KB（单条消息上限） - 若写入超过 64KB，
WriteFile失败并返回ERROR_MORE_DATA，需拆分 - 消息模式下，
ReadFile的lpNumberOfBytesRead返回的是单条消息长度，不是累计字节数
关闭顺序决定资源释放成败，CloseHandle 不等于“立即销毁管道”
命名管道的生命周期由引用计数控制。服务端调用 CloseHandle 后，若客户端句柄仍打开，管道实例不会消失；反之，客户端先关句柄，服务端 DisconnectNamedPipe 后再 CloseHandle，才算彻底清理。
立即学习“C++免费学习笔记（深入）”；
- 服务端处理完一个客户端连接后，必须先调用
DisconnectNamedPipe（仅对已连接句柄有效），再CloseHandle - 客户端退出前调用
CloseHandle即可，但若服务端正阻塞在ConnectNamedPipe，该调用会唤醒它并返回 FALSE（GetLastError() == ERROR_NO_DATA） - 忘记
DisconnectNamedPipe是导致“管道句柄泄漏”和后续连接失败的最常见原因
真正难的不是 API 调用顺序，而是理解 Windows 内核如何把命名管道当作一种“带状态的内核对象”来管理——每个 CreateNamedPipe、CreateFile、ConnectNamedPipe 都在改变它的内部状态机，而文档里很少画出这张状态图。
