命名管道跨平台开发需注意：Windows用CreateNamedPipe需正确设置dwOpenMode和dwPipeMode，Linux用mkfifo需避免O_RDWR竞态；读写应合理分包并统一消息边界处理。
Windows 上用
创建服务端管道
命名管道在 Windows 是同步阻塞 I/O 模型，服务端必须先创建、等待连接，客户端才能连上。直接调用
是最可控的方式，比封装库更易调试。
常见错误是没设对
：比如用了
却没配
，结果读写行为不一致；或者
设成 1，第二个客户端直接
被拒。
必须是
格式，开头双反斜杠不能少，否则
返回
建议设
，避免字节流粘包问题
在阻塞模式下会挂起线程，别在 UI 线程里直接调，容易卡死
Linux 上用
+
模拟命名管道
Linux 没有原生“命名管道服务端/客户端”概念，
创建的是一个特殊文件，靠
的阻塞语义来同步——一端
会等另一端
才返回。
典型坑是两端都用
：Linux 允许，但行为不可靠，某些内核版本下
可能永远返回 0；还有人忘了
后要检查
，重复创建导致失败。
立即学习
“
C++免费学习笔记（深入）
”；
后，权限可能被 umask 截断，建议后续用
补全
服务端应先
尝试打开，再
触发阻塞，避免竞态
不要用
读命名管道——遇到 EOF（对方关闭）会直接失败，改用
判断返回值
和
的缓冲区大小不是越小越好
Windows 下
发送小块数据（比如每次 1 字节），会触发大量系统调用和上下文切换；Linux 下
用太小的缓冲区（如 1 字节），同样效率极低，还可能因管道缓冲区满而阻塞。
C知道
CSDN推出的一款AI技术问答工具
下载
命名管道本身有内建缓冲（Windows 默认 64KB，Linux
通常是 4KB），但应用层仍需合理分包。消息边界不等于 TCP 那种“自动分帧”，得自己处理。
Windows 推荐单次
不超过 64KB，大于这个值会被拆包，且不保证原子性
Linux 下若用
类似语义，得自己加长度头或分隔符，不然
可能只读到半条消息
跨平台代码别假设
一致，长度字段统一用
更安全
客户端连不上时先查
或
连不上不一定是代码逻辑错，更多是环境或权限问题。Windows 下
往往是管道名拼错或服务端根本没启动；
多半是 UAC 权限或服务端用
限制了访问。
Linux 下
表示服务端已关闭或未
读端；
是非阻塞模式下暂时无数据，不是错误。
Windows 客户端用
连接时，
必须和服务端
匹配，比如服务端是
，客户端就不能只请求
Linux 下
看权限位，如果显示
，其他用户进程根本打不开
调试时用
（Win）或
（Linux）确认句柄是否真被占用
命名管道最难的不是写通，而是两边对“消息结束”的理解是否一致。别依赖底层自动切分，老老实实加长度头或换行符——这点比选 API 更关键。
CreateNamedPipeCreateNamedPipedwOpenModePIPE_ACCESS_DUPLEXPIPE_TYPE_MESSAGEnMaxInstancesERROR_PIPE_BUSYlpName\\.\pipe\xxxCreateNamedPipeINVALID_HANDLE_VALUEdwPipeMode = PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAITConnectNamedPipemkfifoopenmkfifoopenopen(O_WRONLY)open(O_RDONLY)O_RDWRreadmkfifoerrno == EEXISTmkfifo("/tmp/my_pipe", 0666)chmodopen(O_RDONLY | O_NONBLOCK)open(O_WRONLY)fscanfreadWriteFilereadWriteFilereadPIPE_BUFWriteFilePIPE_TYPE_MESSAGEreadsizeof(size_t)uint32_tGetLastError()errnoERROR_FILE_NOT_FOUNDERROR_ACCESS_DENIEDSECURITY_DESCRIPTORerrno == ENXIOopenEAGAINCreateFiledwDesiredAccessdwOpenModeGENERIC_READGENERIC_WRITEls -l /tmp/my_pipeprw-------Process Explorerlsof | grep pipe