当命名管道（fifo）的读端断开后，写端继续写入的数据不会被缓存或暂存，而是阻塞在系统调用层面；若写端未做错误检测，程序看似“正常运行”，实则数据根本未进入管道，造成逻辑上的“丢失”。
当命名管道（fifo）的读端断开后，写端继续写入的数据不会被缓存或暂存，而是阻塞在系统调用层面；若写端未做错误检测，程序看似“正常运行”，实则数据根本未进入管道，造成逻辑上的“丢失”。
UNIX 命名管道（FIFO）本质上是一种同步、无缓冲的通信机制——它不提供内核级持久化存储，也不像普通文件或 socket 那样具备发送缓冲区。其核心行为由 POSIX 标准定义：当 FIFO 的读端关闭时，后续对写端的 write() 系统调用将立即返回 SIGPIPE 信号（默认终止进程）或 EPIPE 错误（若忽略 SIGPIPE）；而若写端先于读端打开，则 open(O_WRONLY) 会阻塞，直至有读端打开为止。
在你提供的 producer.go 示例中，关键问题在于：
- os.OpenFile("fifo0", os.O_WRONLY, 0777) 成功返回后，FIFO 写端已建立连接；
- 当 consumer.go 被 Ctrl+C 终止，读端 fd 关闭 → 内核标记该 FIFO 读端为空；
- 此时 fmt.Fprintf(w, ...) 实际调用底层 write()，首次写入会成功（因内核允许少量原子写入），但后续写入将触发 EPIPE 错误；
- 然而 fmt.Fprintf 和 io.MultiWriter 默认忽略写错误，不检查返回值，导致程序继续循环、伪造“数据已发出”的假象。
验证这一点只需添加错误检查：
for i := 0; i < 8000; i++ {
n, err := fmt.Fprintf(w, "%010d%s\n", i, dots)
if err != nil {
log.Printf("Write failed at iteration %d: %v (wrote %d bytes)", i, err, n)
if errors.Is(err, syscall.EPIPE) || errors.Is(err, io.ErrClosedPipe) {
log.Println("Reader disconnected — exiting gracefully")
return
}
}
time.Sleep(time.Millisecond * 10)
}⚠️ 注意事项：
- FIFO 无数据队列：它不像 TCP socket 有发送/接收缓冲区，也不像消息队列可积压消息；所谓“80MB 写入”实为写端循环生成字符串并丢弃，数据从未进入内核 FIFO 队列。
- open(O_WRONLY) 行为：若无读端，该调用会永久阻塞（除非设置 O_NONBLOCK）；但一旦曾建立过读端连接，即使之后断开，写端 fd 仍有效，直到下次 write() 触发错误。
- SIGPIPE 处理：Go 运行时默认屏蔽 SIGPIPE，因此 write() 返回 EPIPE 而非直接崩溃，这正是错误被静默忽略的根源。
总结来说：FIFO 数据不会“堆积”或“丢失在管道中”，而是在读者消失后，写操作立即失效——数据既未传输，也未暂存，只是被写端程序无意识地丢弃。 可靠的 FIFO 应用必须主动检查每次 I/O 的返回值，并依据 EPIPE、EAGAIN 等错误码实现重连、降级或优雅退出逻辑。
