企业官网建设流程全解析

管道这个主题，看起来简单，但每次深挖都能发现值得琢磨的东西。作为进程间通信（IPC）里最基础的实现，它没有共享内存那么高效，没有Socket那么通用，却在 Unix/Linux 世界里活了半个多世纪，任何一门操作系统课、任何一套后端面试题都绕不开它。越是基础的东西越容易被人忽略：管道到底在内核里长什么样？管道符|背后发生了什么？为什么 64KB 缓冲区写满后会卡住进程？这些问题如果不亲手敲代码验证一遍，光看书很容易留下模糊的印象。

这篇文章我会从最底层的pipe()系统调用讲起，配合完整可运行的 C 语言示例，把匿名管道、命名管道 FIFO、Shell 管道符的实现机制串起来。全程不会绕弯子，直接看代码、看内核行为、看实测结果，适合正在学 Linux 系统编程的学生，也适合想把基础补扎实的开发者。

1. 管道在IPC家族中的位置：为什么它是"最基础"的那一个

如果你翻开任何一本操作系统教材，讲到进程间通信，管道一定是排在最前面的。理由很简单：它最贴合"文件"这个 Unix 世界的第一抽象，理解成本最低。但它并不是万能的，在深入代码之前，先把它放回 IPC 家族里看清楚坐标，后面学起来才不会拧巴。

1.1 几类主流 IPC 的底层逻辑对比

Linux 下进程间通信的手段，掰着指头数一下主要包括：管道（匿名管道和 FIFO）、消息队列、共享内存、信号量、信号，以及网络 Socket。它们解决同一个问题——让两个进程交换数据——但思路完全不同。

• 管道：本质是内核里的一块缓冲区，用两个文件描述符代表读端和写端，数据是字节流，有方向性。
• System V 消息队列：以"消息"为单位的链表，每次传递的是带类型标记的结构体，可以随机读取某类消息。
• 共享内存：把同一块物理内存映射到多个进程的地址空间，速度最快，但需要同步机制配合。
• 信号：只传递一个整数编号，不承载数据内容，属于异步通知。
• Socket：跨主机通信的通用方案，本地也有 Unix Domain Socket，机制比管道重。

从这张表能看出来，管道的特点是"轻"和"顺"：轻在只需要两个整数文件描述符就能工作，顺在读写操作完全复用文件 I/O 的接口。对于一个刚接触系统编程的人来说，read()和write()是已经掌握的知识点，管道只是让这两个函数作用于"进程与进程之间"，学习曲线非常平滑。

1.2 字节流模型：管道既简单又受限的根源

管道传递的是无格式的字节流。这意味着写入端不需要指定消息边界，读端拿到的就是一串连续的字节，没有人帮你分包。这个特征带来的后果是双面的：

好处是接口极简，任何类型的数据——文本、二进制、连续的结构体数组——都可以塞进管道，读写双方只要约定好格式就行，内核完全不关心业务语义。Shell 里echo hello | wc -c能工作，正是因为两边都只在处理字节流。

坏处是如果需要"消息边界"，比如希望读端一次读出一个完整的数据包，管道本身做不到。多个进程同时往同一管道写数据时，如果单次写入不超过PIPE_BUF（Linux 上是 4096 字节），内核保证写入是原子的，不会交错；但如果写入长度超过PIPE_BUF，原子性就没了，数据可能被打散。

我见过不少刚开始接触 IPC 的同事，下意识把管道当成消息队列用，期望每次read()都能恰好取回一次write()写入的内容。这个预期在大多数时候能碰巧成立（尤其是单向、单写单读的场景），但一旦加入多个写者或者写入大数据块，就会踩到边界分裂的坑。记住一条判断准则：如果你想传输的是结构化消息，优先考虑消息队列或者自定义带长度前缀的协议；如果你想传输的是连续数据流，管道天然适配。

2. 匿名管道：一次 fork 之后，两个描述符如何变成数据通道

匿名管道的代码可能是所有 IPC 示例里最简短的一段，但很多人只是机械地记住了"先 pipe 再 fork 再关端"这个套路，没想明白每一步的必要性。这一节把完整的调用链拆开，逐行看它背后的语义。

2.1pipe()系统调用分配了什么

在 Linux 下创建一个匿名管道只需要调用：

int fds[2]; int ret = pipe(fds);

pipe()成功返回 0，fds[0]是读端，fds[1]是写端。这个函数在进程内核空间里做了三件事：

1. 分配一个struct pipe_inode_info结构体，里面包含数据缓冲区、读写偏移、等待队列等核心字段。
2. 创建两个关联到同一个管道对象的struct file实例，分别代表读方向和写方向，各自有独立的file操作函数集。
3. 返回两个文件描述符，分别指向这两个file实例。

有一点容易弄混：fds[0]和fds[1]虽然指向同一个管道对象，但它们是两个不同的文件描述符条目，拥有不同的打开文件描述。从 VFS 的角度看，它们对应的file结构不同，只是内部的private_data都指向同一个管道对象。这也是为什么对读端执行read()、对写端执行write()，数据能流到同一块缓冲区的根本原因。

2.2 为什么 fork 之后必须关闭多余的端

管道创建出来之后，当前进程同时持有读端和写端。如果只是单个进程自己跟自己通信，那直接读写就行，但管道真正的价值在于跨进程。所以你几乎总是会紧接着调用fork()：

pipe(fds); pid_t pid = fork();

fork()会把父进程的地址空间完整复制一份给子进程，文件描述符表也一并复制。所以在 fork 完成之后，父子进程手里各有一份fds[0]和fds[1]。此刻系统里一共有 4 个指向管道的文件描述符。

关键点来了：如果子进程只想读，父进程只想写，那么必须在各自进程里把不需要的那一端关掉。子进程关闭写端fds[1]，父进程关闭读端fds[0]。为什么要多此一举？因为管道的生命周期和读写语义都依赖"只有一个读端、一个写端"这个前提。

举一个经典坑：如果负责读的子进程没有关闭继承来的写端，那么即使父进程写完了数据并关闭了自己的写端，读端的read()也永远不会返回 0。因为内核在判断"写端是否全部关闭"时，是统计所有指向该管道写端的file实例数量；只要子进程手里那个多余的写端描述符还开着，内核就认为还有潜在的写者，read()会继续阻塞等待。这个 bug 极其隐蔽，我在 6.2 节会单独展开。

2.3 完整示例：父进程写入，子进程读取

来看一段可以直接编译运行的完整代码：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <sys/wait.h> int main(void) { int fds[2]; char buf[128]; if (pipe(fds) == -1) { perror("pipe"); exit(EXIT_FAILURE); } pid_t pid = fork(); if (pid == -1) { perror("fork"); exit(EXIT_FAILURE); } if (pid == 0) { // 子进程：关闭写端，只保留读端 close(fds[1]); ssize_t n = read(fds[0], buf, sizeof(buf) - 1); if (n < 0) { perror("read"); exit(EXIT_FAILURE); } buf[n] = '\0'; printf("子进程收到: %s\n", buf); close(fds[0]); exit(EXIT_SUCCESS); } else { // 父进程：关闭读端，只保留写端 close(fds[0]); const char *msg = "hello from parent"; write(fds[1], msg, strlen(msg)); close(fds[1]); wait(NULL); } return 0; }

编译运行：

gcc pipe_demo.c -o pipe_demo ./pipe_demo

输出结果：

子进程收到: hello from parent

这个例子里，父进程写入了 17 个字节，子进程一次性全部读出。当父进程关闭写端后，子进程的read()会成功读取到数据；如果父进程在写入前先关闭写端，子进程的read()会立刻返回 0，表示读到 EOF。这个现象不是巧合，而是管道生命周期管理的核心行为，理解了它，才算真正掌握了管道的读写语义。

3. 管道内部分子层面的实现：缓冲区、阻塞唤醒和原子写

管道的用户态接口很简单，但内核态的实现有不少值得说道的细节。很多关于管道"卡住""丢数据"的问题，追到根因都出在这一层。

3.1 64KB 环形缓冲区与读写偏移

Linux 的匿名管道默认容量是 65536 字节，也就是 64KB（FIFO 也相同）。这个数值可以通过fcntl(fd, F_SETPIPE_SZ, size)调整，但上限受系统限制，普通用户默认最大可以调到 1MB，特权进程可以更大。

在内核实现里，管道缓冲区是一个环形结构，核心字段包括：

• base：环形缓冲区的起始地址
• len：当前已用字节数
• read_pos：下一次读取的位置
• write_pos：下一次写入的位置

因为采用环形设计，读写操作不需要移动数据，只需要调整偏移和长度。当write_pos到达缓冲区尾部时，会自动回绕到头部继续写，读端同理。这种设计让读写都可以在 O(1) 时间内完成内存拷贝，性能瓶颈通常不在环形结构本身，而在系统调用带来的上下文切换。

如果你在代码里习惯频繁地小批量写入，比如一次写 4 字节，循环写一万次，性能会非常难看。每一次write()都是一次系统调用，用户态到内核态的切换成本远高于数据拷贝本身。比较合理的做法是自己在应用层做缓冲，攒够一批数据再一次写入。我在第 6 章会再做一次实测对比。

3.2 阻塞与非阻塞：读写双方的等待队列

管道可以设置为阻塞模式（默认）或非阻塞模式。阻塞模式下的行为符合直觉：

• 读端调用read()，如果缓冲区为空，进程会进入睡眠，挂到管道的等待队列上，直到写端写入数据或写端全部关闭。
• 写端调用write()，如果缓冲区剩余空间不足，进程同样会睡眠，直到读端消费了数据腾出空间。

关键在于内核如何唤醒睡眠进程。管道对象维护了一个wait_queue_head_t等待队列，read()和write()在各自的关键路径上都会调用wake_up_interruptible()去唤醒对方。写数据时唤醒读进程，读数据时唤醒写进程。得益于这种对称设计，双方不需要反复轮询，CPU 利用率很高。

非阻塞模式通过fcntl(fd, F_SETFL, O_NONBLOCK)开启。行为变化是：

• 读端在缓冲区为空时，read()立即返回 -1，errno设置为EAGAIN。
• 写端在缓冲区满时，write()立即返回 -1，errno设置为EAGAIN。
• 如果写端没有读端，write()会收到SIGPIPE信号，默认终止进程。

非阻塞模式一般用在事件循环、多路复用场景，配合epoll监听管道读端的可读事件，避免一个读端把整个线程卡死。

3.3 原子写：PIPE_BUF 为什么是 4096 字节

Linux 的PIPE_BUF定义在/usr/include/linux/limits.h，值是 4096。这个值表示"写入该字节数以内的数据，不会被其他写者插入中间"。换句话说，如果两个进程同时向同一个管道写入不超过 4096 字节的数据，内核保证这两份数据在管道里是完整连续存放的，不会你写一半我写一半交织在一起。

内核实现原子性的方法并不复杂：在写入前检查剩余空间是否足够，如果足够，则一次性从用户态拷贝len字节到管道缓冲区，整个操作期间持有管道的锁。如果剩余空间不足，且写入长度大于PIPE_BUF，内核会选择部分写入，把能塞下的先塞进去，剩下的下次再写，这样原子性就没了。

所以如果你的业务场景是多写者单读者，且每条消息不超过 4096 字节，那么可以直接用管道而不需要额外加锁。如果消息更大，就必须自己设计消息边界和确认机制，或者改用消息队列。

3.4 读端关闭时的 SIGPIPE：一个容易忽略的默认行为

当管道读端已经被关闭，写端仍然调用write()时，内核会向写进程发送SIGPIPE信号。这个信号的默认处理是终止进程，所以很多程序会"莫名其妙"地死掉。

为什么会这样设计？因为管道是单向字节流，没有读端的写操作没有任何意义，内核认为这属于程序逻辑错误。与其让写进程卡在无意义的写操作上，不如直接通知它。如果用signal(SIGPIPE, SIG_IGN)忽略掉这个信号，write()才会返回 -1 并且errno被设置为EPIPE。

在实际工程中，很多服务端程序会主动忽略SIGPIPE，然后通过检查EPIPE来决定是否结束数据发送逻辑。尤其是做网络编程的同学，这个习惯应该已经养成了，处理管道时同理。一个典型例子：

signal(SIGPIPE, SIG_IGN); ssize_t ret = write(fds[1], data, len); if (ret == -1 && errno == EPIPE) { // 读端已关闭，处理退出逻辑 }

忽略SIGPIPE本身是个双刃剑：你获得了处理错误的机会，但同时也要承担"没有信号兜底"的责任。如果忘记检查返回值，错误会被静默吞掉，反而更隐蔽。

4. 命名管道 FIFO：跨进程握手不再依赖血缘关系

匿名管道有个天然限制：通信双方必须共享一个祖先进程，因为文件描述符是继承来的。如果两个互不相干的进程需要通信，就得用命名管道，也就是 FIFO。

4.1mkfifo创建了什么

FIFO 在文件系统里有一个真实存在的路径名，用命令mkfifo /tmp/myfifo或者 C 函数mkfifo()创建。从文件系统看它是一个特殊类型的文件，ls -l会显示类型为p：

$ mkfifo /tmp/myfifo $ ls -l /tmp/myfifo prw-r--r-- 1 user user 0 Nov 18 10:00 /tmp/myfifo

但这里的"文件"只是路径入口，真正的数据存储在内核的管道对象里。文件系统上的 FIFO 文件不占用磁盘数据块，它只是为了让进程能够通过路径找到同一个内核管道对象。打开 FIFO 的时候，VFS 根据 inode 的类型识别出这是 FIFO，然后调用 FIFO 专用的open逻辑，而不是普通的磁盘文件打开逻辑。

4.2open()的阻塞语义：两个方向必须匹配

FIFO 的open()有一个非常容易踩坑的行为：以只读方式打开 FIFO 会阻塞，直到另一个进程以只写方式打开同一个 FIFO；反之亦然。也就是说，读写双方必须"配对"出现，open()才会返回。

这跟匿名管道创建后立即拥有两端不同，FIFO 是逐步建立的连接。你在 Shell 里做实验最容易感受到：

# 终端 1：这会阻塞，因为还没有写端 cat /tmp/myfifo # 终端 2：写入数据后，终端 1 的 cat 立刻返回 echo "hello" > /tmp/myfifo

有读者可能问：如果不想让open()阻塞怎么办？传入O_NONBLOCK标志即可。此时以只读方式打开 FIFO 会立即返回，即使没有写端；但是以只写方式打开且没有读端时，open()会立即失败，返回ENXIO。因为写端没有读端配对，写数据毫无意义，内核干脆拒绝打开。这个不对称设计在编写服务端守护进程时需要注意，很容易在启动顺序上调半天。

4.3 实战场景：两个独立进程通过 FIFO 交换命令

我写过一个简单的数据采集程序，采集进程和上报进程是两个独立的二进制，通过 FIFO 传递指令。核心逻辑如下：

// 发送端：发送指令给接收端 #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <sys/stat.h> int main(void) { const char *fifo = "/tmp/cmd_fifo"; mkfifo(fifo, 0666); int fd = open(fifo, O_WRONLY); if (fd == -1) { perror("open"); exit(EXIT_FAILURE); } const char *cmd = "reload_config"; write(fd, cmd, strlen(cmd) + 1); close(fd); return 0; }

// 接收端：等待并执行指令 #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <sys/stat.h> int main(void) { const char *fifo = "/tmp/cmd_fifo"; mkfifo(fifo, 0666); char buf[256]; while (1) { int fd = open(fifo, O_RDONLY); if (fd == -1) { perror("open"); break; } ssize_t n = read(fd, buf, sizeof(buf) - 1); if (n > 0) { buf[n] = '\0'; printf("收到指令: %s\n", buf); } close(fd); } return 0; }

注意接收端的while循环里，每次收到指令后close(fd)，下次循环再open()。这是因为发送端写完即关闭，管道里没有了写端，接收端的read()会返回 0 代表 EOF。如果接收端不关闭再重开，后续发送端再次open()时就会因为没有读端而阻塞。这个"每次通信重新建立连接"的模型，是 FIFO 以命令为单位通信时的常见写法。

不过这个模型有性能问题：每次收发都要重新open()和close()，系统调用开销不小。如果你希望连接长期保持，可以约定发送端打开后不关闭，接收端持续read()，直到收到某个特定的退出指令。两种模式的取舍，取决于数据是"离散指令"还是"长连接流"。

5. Shell 里的一根竖线：管道符背后隐藏的进程拓扑

我们每天都在用它，grep "error" app.log | wc -l，但未必想过这一根|到底是怎么把两个进程接起来的。这一节从 Shell 的视角看管道的完整生命周期。

5.1 Shell 解析管道符后的 fork/exec 序列

Shell 解析到cmd1 | cmd2时，会执行大致如下的步骤：

1. 调用pipe()创建匿名管道，得到fds[0]和fds[1]。
2. fork()第一个子进程，用于运行cmd1。在这个子进程里，把标准输出STDOUT_FILENO重定向到fds[1]，关闭fds[0]，然后exec()加载cmd1。
3. fork()第二个子进程，用于运行cmd2。在这个子进程里，把标准输入STDIN_FILENO重定向到fds[0]，关闭fds[1]，然后exec()加载cmd2。
4. 父进程（Shell）关闭自己的fds[0]和fds[1]，然后wait()等待两个子进程结束。

重点在于第 4 步：Shell 必须关闭自己持有的管道描述符。如果 Shell 不关闭，管道写端就会因为多了一个引用而迟迟不产生 EOF，cmd2的标准输入会一直阻塞等待，导致整条链路的命令无法结束。这也是为什么你在写 C 程序模拟 Shell 行为时，要特别注意"父进程也要关闭管道两端"。

5.2 多个管道连续拼接时的进程链

cmd1 | cmd2 | cmd3这样的长链路，本质上是在多个管道间做串接。Shell 会先创建管道 1（连接 cmd1 和 cmd2），再创建管道 2（连接 cmd2 和 cmd3），然后分别 fork 三个子进程。cmd2 进程的输入来自管道 1，输出去往管道 2，它就像一个中继站。

在进程数量多的时候，管道的连接关系需要小心管理。cmd2 子进程除了拿到管道 1 的读端和管道 2 的写端之外，还继承了一些本不该继承的描述符。如果不显式关闭，写端的引用计数就不会归零，EOF 传播会出问题。Shell 在处理长管道时会逐个子进程关闭不需要的端，保证数据流是严格单向的。

5.3 管道导致的部分输出延迟现象

执行yes | head -n 100时，yes会无限输出，但head只需要 100 行就会退出。yes进程是怎么停止的？答案是：head退出后关闭了管道读端，yes下一次write()时收到SIGPIPE，默认终止。这就是为什么yes不会永远跑下去。

反过来，grep和sort这类命令经常会"吞"输出：grep的输出是边读边写，但sort必须等所有输入到达后才能排序。所以cat huge_file | sort这种写法，sort会先把整个文件吃进内存或磁盘临时文件，再输出结果。从用户体验上看，sort似乎"卡住"很久，其实它在等待 EOF。如果你不确定一个命令是流式处理还是全量处理，一条黄金法则是：看它会不会在读完所有输入之前产生输出。grep会流式输出，sort不会。

6. 真实踩坑记录：管道使用中的那些坑，每一个我都付过学费

这一节记录我个人在实际工程里踩过的管道相关的坑。有些坑在书上看不到，只有等进程真的"卡死"或者"丢数据"之后才明白原因。

6.1 缓冲区写满导致的死锁：谁来消费数据？

有一个多进程并行计算的场景：父进程生成任务，分发给多个子进程。我用一个匿名管道作为任务队列，父进程往里写任务。问题来了：任务量很大，管道缓冲区很快写满，父进程阻塞在write()上，等着某个子进程来读。但子进程的工作模型是"完成当前任务后再读下一个"，它们先执行完一批任务后，才会回到管道读取。整体节奏看起来没问题，但一旦某个子进程处理异常变慢，消费速度跟不上生产速度，父进程就会一直阻塞在write()上。

这个坑的本质是：管道不是一个无限容量的消息队列，它的背压直接作用于写端。如果你需要生产者可以"阻塞式地等待消费者"，那没问题；如果你需要生产者能够缓冲大量任务，避免被一个慢消费者拖住，管道就不合适了。我当时改用有界任务队列，把任务放到文件或数据库里，子进程主动拉取，效果立刻改善。

排查这类问题时，strace是利器。执行strace -p <pid>查看进程卡在哪个系统调用上，如果长时间停留在write()或者read()，基本可以确认是管道阻塞。加上-e trace=read,write过滤后，定位更精准。

6.2 忘记关闭写端导致read()收不到 EOF

这是新手最容易忽略的问题。子进程继承父进程的全部文件描述符，如果你在fork()之后没有在子进程里关闭写端，那么父进程关闭了写端也没用，因为子进程手里还握着写端的副本。内核判断"写端是否全部关闭"依据的是所有指向同一管道对象的写端file实例计数，不是某一个进程的行为。

症状非常典型：读端的read()一直阻塞，永不返回 0。你检查父进程，发现它确实已经关闭了写端，数据也写完了，但读端就是等不到 EOF。原因就在某个子进程的继承描述符里。

修复方法也很简单：fork()之后立刻在子进程里关闭不需要的端，在父进程里关闭不需要的端。这不仅是代码规范，更是正确性要求。一个辅助手段是，在pipe()之后立刻把两个 fd 都加上FD_CLOEXEC，这样exec()执行新程序时，这些描述符会自动关闭，可以隔离继承污染：

int fds[2]; pipe(fds); fcntl(fds[0], F_SETFD, FD_CLOEXEC); fcntl(fds[1], F_SETFD, FD_CLOEXEC);

6.3 非阻塞模式的EAGAIN处理

把管道设置为非阻塞之后，read()在缓冲区为空时返回 -1 且errno为EAGAIN。这个返回值经常被误判为错误。正确逻辑是：当read()返回 -1 时，先检查errno，如果是EAGAIN，说明暂时没数据，可以把当前 fd 加入epoll等待可读事件。

我见过一个真实事故：某个监控程序把 FIFO 设置为非阻塞读，但read()收到EAGAIN后没有妥善处理，而是直接 break 出循环，导致后续再无数据被消费，FIFO 缓冲区越积越多，最终所有写端全部被阻塞。排查半天才发现是EAGAIN被当成错误处理了。

6.4 小写入的性能陷阱：一万次write()的代价

写一个测试程序：向管道写入 1GB 数据，分别用 4 字节小写入和 4KB 大块写入对比。结果可能出乎意料：4 字节写入耗时是 4KB 写入的数十倍乃至上百倍。原因很简单，每次write()都是用户态到内核态的系统调用，就算拷贝的数据量少，固定开销还在。4 字节写一万次，相当于做了一万次上下文切换。

优化方向是把小数据合并成大块，在用户态维护一个缓冲区，达到一定阈值才调用一次write()。标准 C 库的stdio缓冲区（setvbuf）就是这种思路。如果数据本身是结构化的小包，建议在写入前做封包，粘成一个大 buffer，一次性写入。

6.5 管道读写方向搞反：数据流向必须确认

管道是单向的，数据永远从写端流向读端。如果你把读端当成写端用，write()会返回 -1，errno为EBADF。这个报错比较直接，但有一种隐蔽的相反情况：你拿着写端的 fd 去调用read()，返回的也是EBADF。所以代码里所有的read()都应当作用于fds[0]，所有的write()都应当作用于fds[1]。在大型项目里，建议把读端和写端封装成不同名字的变量，避免混淆。

7. 什么时候别用管道：结合场景判断 IPC 选型

管道不是万能的，它的简单性同时也是它的天花板。搞清楚什么时候不应该用管道，比学会怎么用管道更重要。

7.1 大数据量高吞吐场景：共享内存 + 同步机制才合适

管道每次读写都要经过系统调用，数据要从用户态拷贝到内核缓冲区，再从内核缓冲区拷贝到另一个进程的用户态。这中间至少两次内存拷贝，还没有计算上下文切换的开销。如果是 GB 级数据持续传输，管道的吞吐量远低于共享内存——共享内存只需要一次拷贝，进程直接访问同一块物理内存，速度能高一个数量级。

当然，共享内存的问题是需要自己处理同步和互斥，通常搭配信号量或互斥锁使用，开发复杂度显著上升。如果你对性能有极致追求，或者数据传输量巨大，可以考虑共享内存；如果你的瓶颈不在 IPC 吞吐上，管道完全够用，还省心。

7.2 多对多通信场景：消息队列或消息中间件更合适

管道天然优化"一写一读"或"多写单读"模型。如果通信拓扑是 N 个进程需要互相收发消息，用管道来组织描述符关系会变得极其复杂，每一条通信链路要两个管道（双向）或者严格约定半双工。这种情况下消息队列更合适，它天然支持多个生产者、多个消费者，消息有类型标记，可以按需读取。

7.3 跨主机场景：Socket 无法替代

管道只存在于单台主机内部，跨主机必须用网络协议。即使是两台机器之间的本机通信，也要走AF_UNIX或 TCP/UDP。AF_UNIX虽然也叫 Socket，但它其实是介于管道和网络 Socket 之间的选择：本机内传输、路径名寻址、数据可靠，很多现代中间件（比如 Redis、Nginx 的某些内部通信）都采用AF_UNIX。

7.4 IPC 选型速查表

管道作为 IPC 的入门关卡，价值不在于它有多强大，而在于它是理解一切更复杂通信机制的基石。管道让你体会到文件描述符、内核缓冲区、阻塞唤醒、信号与 EOF 这些概念如何协作。把这些搞透了，再去看 Socket、看共享内存、看消息队列，都会觉得顺理成章。

我自己的体会是，学管道不能只停留在 API 层面，必须配合strace和简单的 C 程序做实验：看看阻塞时卡在哪个系统调用，看看SIGPIPE来了会怎样，看看非阻塞模式下的EAGAIN长什么样。这些实验花不了多少时间，但对建立系统编程的感觉，帮助比读十篇文章都大。