pipe是单向、匿名、仅限亲缘进程的内核环形缓冲区，需fork后使用且须关闭冗余fd；AF_UNIX socket才是功能可比的本地IPC方案，支持双向、寻址、非亲缘进程通信。
Linux 下 pipe 和 socket 都能传数据，但它们根本不是同一类工具：前者是单向、匿名、仅限亲缘进程的内核缓冲区；后者是双向、可跨主机、需显式地址绑定的网络抽象。别拿 pipe 去替代 socket，也别指望 socket 在父子进程间自动继承。
pipe 只在 fork 后父子进程间有效，且只能单向通信
pipe 创建一对文件描述符：fd[0]（读端）、fd[1]（写端），本质是内核维护的一块环形缓冲区。它不涉及地址、协议或网络栈，也不支持非亲缘进程（如两个独立启动的 shell 进程）直接使用。
常见错误现象：
- 子进程未关闭不用的 fd，导致父进程
read永远阻塞（因为写端未真正关闭） - 在多线程中 fork 后未重置
pipe的 fd 标志位（如O_CLOEXEC未设），引发意外继承 - 误以为
pipe支持select/epoll多路复用 —— 实际支持，但仅限本地 fd，不能跨机器
典型用法：
int fd[2];
if (pipe(fd) == -1) { /* handle error */ }
if (fork() == 0) {
close(fd[0]); // 子进程只写
write(fd[1], "hello", 5);
close(fd[1]);
} else {
close(fd[1]); // 父进程只读
char buf[6];
read(fd[0], buf, 5);
close(fd[0]);
}socket 是通用通信原语，AF_UNIX 本地 socket 才接近 pipe 的定位
真正和 pipe 功能可比的是 AF_UNIX 类型的 socket（又称 local socket 或 Unix domain socket）。它支持双向、全双工、可寻址（通过文件路径）、可被非亲缘进程访问，且性能接近 pipe（零拷贝优化在较新内核已支持）。
关键差异点：
-
AF_UNIXsocket 需要bind()绑定一个路径（如/tmp/mysock），而pipe完全无地址概念 -
AF_UNIX支持SOCK_STREAM（可靠字节流，类似 TCP）和SOCK_DGRAM（不可靠数据报，类似 UDP），pipe仅提供字节流语义 -
AF_UNIX可以用connect()+accept()建立连接，天然支持一对多模型；pipe固定一对一
示例（服务端监听 /tmp/echo.sock）：
int s = socket(AF_UNIX, SOCK_STREAM, 0);
struct sockaddr_un addr = {.sun_family = AF_UNIX};
strncpy(addr.sun_path, "/tmp/echo.sock", sizeof(addr.sun_path)-1);
bind(s, (struct sockaddr*)&addr, offsetof(struct sockaddr_un, sun_path) + strlen(addr.sun_path));
listen(s, 1);
int c = accept(s, NULL, NULL); // 阻塞等待客户端
char buf[1024];
read(c, buf, sizeof(buf)-1);
write(c, buf, strlen(buf));为什么不该用 AF_INET socket 替代 pipe 做本地进程通信
用 AF_INET + localhost:12345 实现本机 IPC 看似可行，但会引入不必要的开销和复杂性：
- 走完整 TCP/IP 协议栈（即使绕过网卡，仍需 socket 层、TCP 状态机、time-wait 等）
- 端口竞争风险：多个实例可能 bind 失败，需额外逻辑选端口或重试
- 权限模型不同：
AF_UNIXsocket 可用文件系统权限控制访问（chmod/chown），AF_INET依赖 netfilter 或 CAP_NET_BIND_SERVICE - 调试困难：
netstat -tuln显示的是网络端口，而非进程关系；lsof -U才能看到AF_UNIXsocket 路径与进程映射
除非你明确需要跨主机、或复用已有网络库接口，否则本地 IPC 场景下优先选 pipe（父子简单传递）或 AF_UNIX socket（任意进程、双向、结构化）。
容易被忽略的边界情况：pipe 容量与 SIGPIPE
pipe 缓冲区大小并非无限，默认通常是 64KB（cat /proc/sys/fs/pipe-max-size 可查），写入超限时 write() 会阻塞（或返回 EAGAIN，若设 O_NONBLOCK）。更隐蔽的问题是 SIGPIPE：当写端往已关闭读端的 pipe 写数据时，进程默认终止。
规避方式：
- 总是检查
write()返回值，不假设一次写完 - 对不需要的信号做屏蔽：
signal(SIGPIPE, SIG_IGN) - 用
splice()或sendfile()避免用户态拷贝（仅限 Linux，且要求一端是文件或 socket） -
AF_UNIXsocket 不触发SIGPIPE，write()返回-1+EPIPE，可控性更好
实际开发中，越早决定通信粒度（一次性小数据？持续流？是否需认证？是否需广播？），越容易避开 pipe 和 socket 的错配陷阱。
