windows的createnamedpipe与linux的mkfifo语义不等价：前者创建即返回句柄并需立即connectnamedpipe，后者仅建文件节点、依赖open()激活管道；跨平台需抽象服务器初始化和客户端连接两阶段。
Windows上用CreateNamedPipe替代mkfifo，但语义不等价
Linux的mkfifo只创建一个文件系统节点，后续靠open()阻塞等待读写端；Windows的CreateNamedPipe直接创建并返回句柄，且必须立刻调用ConnectNamedPipe或设置为非阻塞——这是最常踩的坑：很多人写了CreateNamedPipe就以为管道“已就绪”，结果另一端CreateFile失败，报错ERROR_PIPE_BUSY或ERROR_FILE_NOT_FOUND。
典型场景是服务端启动后监听管道，客户端按需连接。服务端不能只调一次CreateNamedPipe就完事，得循环调用ConnectNamedPipe（成功后继续下一轮），或者用异步I/O配OVERLAPPED。
-
PIPE_TYPE_MESSAGE和PIPE_READMODE_MESSAGE要配对使用，否则ReadFile可能截断消息 - 默认缓冲区大小是64KB，大消息需显式设
nOutBufferSize参数，否则WriteFile会失败并返回ERROR_NO_DATA - 路径格式必须是
\\.\pipe\myapp，少一个或拼错pipe都会导致ERROR_INVALID_NAME
Linux用mkfifo后必须open()两次才能通信
mkfifo只是建个特殊文件，不分配内核资源；只有至少一个O_RDONLY和一个O_WRONLY的open()同时存在，管道才算“激活”。常见错误是服务端只open(O_RDONLY | O_NONBLOCK)，客户端open(O_WRONLY)时卡住——因为没读端在等，O_WRONLY会阻塞（除非加O_NONBLOCK，但此时会直接返回-1并设errno = ENXIO）。
所以典型流程是：服务端先mkfifo，再open(O_RDONLY | O_NONBLOCK)占位，等客户端open(O_WRONLY)成功后，服务端再open(O_RDONLY)（阻塞式）开始读；或者两端都用O_RDWR打开，但这样无法区分方向，且POSIX不保证原子性。
立即学习“C++免费学习笔记（深入）”；
-
mkfifo的权限掩码受umask影响，mkfifo("p", 0666)实际可能是0644，跨用户通信要显式chmod - 路径长度限制：Linux一般为
PATH_MAX（通常4096），但FIFO路径若过长，open()可能返回ENAMETOOLONG - 不要在
/tmp里用随机名+mkfifo做IPC——unlink()后文件节点消失，但已打开的fd仍有效；新进程可能误连旧fd残留的管道
跨平台封装的关键：抽象出“服务器端初始化”和“客户端连接”两阶段
不能简单用#ifdef _WIN32切函数，因为生命周期和错误处理逻辑完全不同。比如Windows服务端创建后必须立即ConnectNamedPipe，而Linux服务端mkfifo后可以等很久才open；客户端在Windows上CreateFile失败要重试（因服务端可能还没调ConnectNamedPipe），Linux上则要看open是否被信号中断（EINTR）或无读端（ENXIO）。
建议把接口拆成两个函数：pipe_server_init(const char* name)负责平台相关创建+准备等待，pipe_client_connect(const char* name)负责连接并返回可读写句柄/fd。内部各自处理重试、超时、错误映射（如把ERROR_PIPE_BUSY转成EAGAIN）。
- Windows端
CreateNamedPipe的nMaxInstances设为PIPE_UNLIMITED_INSTANCES看似方便，但实际受系统资源限制，大量并发连接时可能静默失败 - Linux端若用
inotify监听FIFO路径变化来触发连接，要注意IN_CREATE事件不代表mkfifo已完成，得再stat()确认类型是S_IFIFO - 路径分隔符统一用
/，Windows运行时由CRT自动转换，别手动生成\\.\pipe\...字符串
调试时ERROR_ACCESS_DENIED和EACCES大概率是权限或UAC问题
Windows上非管理员进程默认不能创建全局命名管道（\\.\pipe\...），会直接报ERROR_ACCESS_DENIED；Linux上mkfifo失败若返回EACCES，通常是父目录没有w权限，而非FIFO自身权限问题。
更隐蔽的是Windows UAC虚拟化：当程序以标准用户运行却尝试写C:\Program Files下的路径时，系统会悄悄重定向到%LOCALAPPDATA%\VirtualStore，导致管道路径实际不一致——服务端在真实路径创建，客户端却连向虚拟路径，必然失败。
- Windows调试时用
procexp.exe搜索pipe能直接看到已创建的命名管道及其所有者、句柄数 - Linux用
lsof | grep FIFO或find /proc/*/fd -type p 2>/dev/null -ls查哪些进程打开了FIFO - 跨平台日志里别只打“pipe connect failed”，一定要带上
GetLastError()或errno值，否则根本分不清是路径错、权限错还是对方没启动
事情说清了就结束
