匿名管道不能直接传大文件，因系统缓冲区仅64KB，超量写入会阻塞；须分块读写、双向同步，父子进程需fork前创建pipe并正确关闭冗余端。
pipe() 创建的匿名管道能传大文件吗
不能直接传，会卡死或丢数据。系统 pipe buffer 通常只有 64KB（Linux 默认），write() 写入超过缓冲区大小时会阻塞，而读端如果没及时 read()，写端就永远等下去——尤其是传几十 MB 文件时，极易僵住。
真正可行的做法是：分块读写 + 双向同步控制。不是“把整个文件塞进 pipe”，而是“一边从文件 fread()，一边往 pipe write()；另一边从 pipe read()，再 fwrite() 到目标文件”。
- 每次
read()和write()都要检查返回值，0表示 EOF，负值表示错误（如EAGAIN） - 推荐块大小设为
8192或65536，避开小包开销又不压爆 buffer - 父子进程必须明确分工：父进程写文件 → pipe，子进程读 pipe → 写文件；或反过来，但不能两边都读/都写
fork() 后父子进程怎么安全共享 pipe 文件描述符
调用 pipe() 必须在 fork() 之前，否则子进程拿不到同一组 fd。常见错误是先 fork() 再 pipe()，结果父子各有一对无关的管道。
关键操作顺序：
立即学习“C++免费学习笔记（深入）”；
-
int pipefd[2]; pipe(pipefd);—— 创建成功后得到pipefd[0]（读端）、pipefd[1]（写端） -
pid_t pid = fork();—— 此时子进程自动继承这两个 fd - 父进程立刻
close(pipefd[0]);（不读），子进程立刻close(pipefd[1]);（不写） - 双方各自用剩下的 fd 通信，避免资源泄漏和死锁
漏关某端会导致 read() 永远等不到 EOF（因为内核认为“可能还有人没关写端”）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
如何避免 read() 返回 EINTR 或 EAGAIN 导致传输中断
信号中断（EINTR）和非阻塞模式下的无数据（EAGAIN）都会让 read() 或 write() 提前返回 -1，但不代表出错，更不意味传输结束。
正确处理方式：
- 对
read()：遇到EINTR就重试；遇到EAGAIN且 pipe 是非阻塞的，需用poll()或select()等待可读事件 - 对
write()：同理，EINTR重试，EAGAIN等待可写 - 实际中更稳妥的是：创建 pipe 后，不要用
fcntl(pipefd[1], F_SETFL, O_NONBLOCK)，保持默认阻塞行为，靠分块读写自然规避
强行设非阻塞，反而要把逻辑写得又臭又长；默认阻塞 + 正确 close + 分块循环，足够健壮。
Windows 上 CreatePipe() 和 _open_osfhandle() 怎么配对使用
Windows 没有 POSIX pipe，必须用 CreatePipe() 创建句柄，但 C 标准库函数（如 fread()）只认 FILE* 或 int fd，所以得桥接。
核心转换链：
- 用
CreatePipe()得到HANDLE hRead和HANDLE hWrite - 用
_open_osfhandle((intptr_t)hRead, _O_RDONLY)转成 C 运行时 fd - 再用
fdopen(fd_read, "rb")转成FILE*，才能配合fread()/fwrite() - 注意：
hRead和hWrite仍需手动CloseHandle()，fdopen()不接管句柄生命周期
漏掉 _open_osfhandle() 这步，直接把 HANDLE 当 fd 传给 read()，会触发 EBADF 错误——这是 Windows 下最常踩的类型混淆坑。
