命名管道FIFO进程间通信原理与实战：从阻塞机制到选型对比

1. 为什么还在聊命名管道：一对多的场景里它最省事

有一次调一个采集系统的偶发丢事件问题，我把数据链路从头到尾捋了一遍，最后定位到不是程序逻辑，而是两个进程之间用临时文件当通道——写端和读端各管各的，文件被覆盖了都没人知道。后来我把这条链路换成了命名管道（Named Pipe / FIFO），问题一次解决。这篇文章就把命名管道通信这条路的原理、代码、坑和选型讲透。

先说清楚命名管道是什么。它本质上是内核维护的一块缓冲区，通过文件系统里的一个特殊文件暴露出来。进程A往这个文件里写，进程B从这个文件里读，数据不落盘，在内核里完成转交。Linux里管它叫FIFO，用mkfifo创建；Windows里叫Named Pipe，用CreateNamedPipe创建。两者思路一致，但细节差别不小，后面分开讲。

我之所以说"一对多场景里它最省事"，是因为在单机多进程里，你常见的通信手段无非这么几种：pipe匿名管道、System V消息队列、共享内存、Unix Socket、TCP Socket。它们各有脾气，但很多场景下都有点"过度设计"的味道。共享内存快是快，可你得自己管同步、锁、生命周期，出错就是段错误挂掉；Socket功能全，但为了本地两个进程还要走协议栈、管连接状态，属实有点牛刀杀鸡。命名管道在这两者之间给了个非常舒服的平衡点：不用管连接建立，打开文件就能读写，多个读端可以同时读同一份数据，天然带阻塞流控，写端不会一脚油门把内存打爆。

这里要特别强调一下"多个读端"这件事。很多时候你做监控、做日志采集，希望一份事件数据同时被两个消费者拿到，此时命名管道有个现成的优势——数据在管道里广播式分发，每个打开读端的进程都能拿到一份。虽然消息队列也能做类似的事，但命名管道的方式对已有系统侵入最小，你甚至不需要引入中间件，进程结构也完全不用改，只是把原来的文件读写换成FIFO读写。

这篇文章主要面向两类人：一类是在Linux下做嵌入式、边缘网关、后台服务开发，经常被进程间通信折腾的工程师；另一类是Windows平台做桌面软件，需要在不同进程间传配置、传事件通知的朋友。我会把原理、可运行的代码、最常见的坑、以及和共享内存/Socket的选型边界一次讲清楚。

2. 命名管道在Linux下的运行机制：从mkfifo到阻塞队列

2.1 mkfifo创建了什么

Linux下创建命名管道就是一条命令的事：

bash复制mkfifo /tmp/event_pipe.fifo

创建完之后用ls -l看一眼，你会发现文件类型是p而不是-：

bash复制prw-r--r-- 1 user user 0 Feb 20 10:30 /tmp/event_pipe.fifo

注意文件大小永远是0。这一点是理解命名管道的关键：这个文件只是给用户一个"抓手"，数据根本不在文件里，文件系统上没有任何数据块，所有数据都在内核的管道缓冲区中。所以拿stat看大小、拿du算占用，都是白费力气，它同样不会占用磁盘。

你可以把管道想象成一根真实的水管，文件节点是水龙头的位置标志，水（数据）在水管里流动，水管本身是内核缓冲区。两头都不开的时候，水只能在管子里存着；管子满了再灌水，灌水的人就得停下来等着。

2.2 读写阻塞与原子性：两个最容易被误解的特性

命名管道的阻塞行为分两阶段，很多人栽在这上面。

第一个阶段发生在open的时候。如果你用只读方式打开一个管道，这个open调用会一直阻塞，直到有一个写端也打开同一个管道为止。反过来也一样——写端open会阻塞等待读端。也就是说，管道的两端必须"配对"出现，进程才算真正拿到这个文件描述符。

第二个阶段发生在读写的时候。如果读端在读一个空管道，调用会阻塞，直到写端写入数据；如果写端在写一个满了的管道，调用会阻塞，直到读端读走一些数据腾出空间。这个特性让它天然成为流控机制：慢消费者不会被快生产者冲垮，生产者的写调用会自然放慢。

再说原子性。Linux的FIFO有个写入原子性保证：如果单次写入的数据大小不超过PIPE_BUF（这个值通常等于4096字节），且管道缓冲区内有足够的空间，那么这次写入是原子的。这意味着多个写端同时往里写小数据包时，内核保证每个包要么被完整写入，要么完全不写，不会出现两个进程的数据交织在一起的情况。

我举个例子说明这个原子性有多重要。假设两个告警进程同时向同一个管道写入告警消息，每个消息是"ALARM: cpu_high, core=3"这样200字节左右的文本。因为每条消息都小于4096，内核会保证读端每次读到的都是完整的单条消息，不会出现"A进程的半个消息+B进程的半个消息拼在一起"的脏数据。这在实践中帮了我大忙，省去了在应用层加互斥锁的麻烦。

但注意，这个原子性只对单次写入小于PIPE_BUF的小包有效。如果你单次写超过这个大小，系统不再保证原子性，读端可能读到半包数据。另外它也不保证"流边界"——如果你连续写两条不超过4096的消息"HELLO"和"WORLD"，读端可能会在一次read里拿到"HELLOWORLD"，也可能分两次拿，全看当时管道缓冲区的状态和调度时机。所以真正的消息边界，应用层还是要自己定协议，后面第三节会讲。

2.3 半双工的事实：为什么双向交互要开两条管道

命名管道的数据流是单向的。你从一个FIFO文件读，就往另一个FIFO文件写。一个FIFO文件本身没有"双向"的概念。写成代码就是：

c复制int fd_read = open("/tmp/pipe_a", O_RDONLY);
int fd_write = open("/tmp/pipe_b", O_WRONLY);

想要两个进程互相发消息，就得创建两个方向相反的FIFO，每个进程一边读一个、一边写一个。这是和Socket的一大区别——TCP连接是天然全双工的，读写同一个描述符就行。不少第一次用FIFO的人会下意识往同一个管道里一边写一边读，结果发现数据总是读不到自己写的内容，那正是因为没理解这个单向性。

如果你去看内核源码的pipe实现，会发现它的数据结构本质就是一个环形缓冲区，有一个head指针和一个tail指针。写入把数据追加到head，读取从tail取出，当两个指针相遇且没有数据时，读端阻塞。这个环形缓冲区的设计决定了它的几个特征：不支持任意位置的随机读写，只能顺序读；缓冲区大小固定（默认通常64KB，现代内核里还可以通过F_SETPIPE_SZ调节）；缓冲区满载时写入行为是阻塞等待，而不是直接丢弃。

了解了这些底层的"为什么"，你就能预判很多后续问题。比如为什么高吞吐场景下管道会变成性能瓶颈——环形缓冲区加锁、内核态用户态拷贝，每一步都有代价。再比如为什么进程崩溃后管道文件还留在磁盘上——文件是持久存在的，但缓冲区里的数据会随所有打开文件描述符的关闭而丢失。

3. 实战：搭一套双进程事件分发通道

3.1 场景定义与消息协议

理论说再多，不如跑一个真实例子。我这里设计一个典型的边缘网关场景：采集进程（producer）不断产生设备告警事件，事件要同时发给两个下游消费者——一个实时告警展示前台，一个落盘审计日志后台。

协议我选择最简单实用的"长度前缀+JSON体"方案。每条消息由四字节小端整数len开头，后面跟着len字节的JSON文本。虽然管道本身对小于4096的小包有原子性保证，但一旦消息体超过这个阈值，或者内核把多次写入合并后再交给读端，没有显式边界就会出问题。所以无论消息多小，我都建议把边界协议放进去，这也算是个好习惯。

消息格式如下：

json复制{"type":"alert","level":3,"source":"sensor_01","ts":1737000000,"msg":"temperature high"}

3.2 服务端与客户端代码骨架

完整的多进程工程用C++写会很啰嗦，但原理完全一样。这里为了让大家快速跑通，我用Python写一套干净的实现。先看写端（生产者）：

python复制import json
import os
import struct
import time

FIFO_PATH = "/tmp/event_pipe.fifo"

def ensure_fifo(path: str):
    if not os.path.exists(path):
        os.mkfifo(path)

def write_message(fd, obj: dict):
    body = json.dumps(obj, ensure_ascii=False).encode("utf-8")
    header = struct.pack("<I", len(body))
    fd.write(header)
    fd.write(body)
    fd.flush()

def main():
    ensure_fifo(FIFO_PATH)
    print(f"opening FIFO for writing: {FIFO_PATH}")
    fd = open(FIFO_PATH, "wb", buffering=0)
    seq = 0
    while True:
        msg = {
            "type": "alert",
            "seq": seq,
            "level": seq % 5,
            "ts": int(time.time()),
            "msg": f"temperature high at sensor_{seq % 10}",
        }
        write_message(fd, msg)
        print(f"sent seq={seq}")
        seq += 1
        time.sleep(1)

if __name__ == "__main__":
    main()

几个细节值得说明。第一，open这里我用了buffering=0，也就是无缓冲的二进制写模式，确保数据不经过Python这一层缓冲直接进内核管道。之前我见过有人用默认的缓冲写，结果生产者发出去的消息在消费者侧迟迟看不到，就是因为数据攒在Python自己的缓冲区里没flush出去。第二，os.mkfifo如果发现文件已存在就不会重复创建，但启动前最好确认这个文件不是之前的残留，否则可能打开的是陈旧文件。

再看读端（消费者），我起了两个进程，分别代表告警前台和审计日志：

python复制import json
import os
import struct
import sys

FIFO_PATH = "/tmp/event_pipe.fifo"

def read_exact(fd, n: int) -> bytes:
    chunks = []
    remaining = n
    while remaining > 0:
        chunk = fd.read(remaining)
        if not chunk:
            raise EOFError("fifo closed by writer")
        chunks.append(chunk)
        remaining -= len(chunk)
    return b"".join(chunks)

def main(tag: str):
    print(f"[{tag}] opening FIFO for reading: {FIFO_PATH}")
    fd = open(FIFO_PATH, "rb", buffering=0)
    while True:
        try:
            header = read_exact(fd, 4)
            (body_len,) = struct.unpack("<I", header)
            body = read_exact(fd, body_len)
            obj = json.loads(body)
            print(f"[{tag}] got seq={obj['seq']} level={obj['level']}")
        except EOFError:
            print(f"[{tag}] writer closed, exit")
            break
        except Exception as e:
            print(f"[{tag}] error: {e}")
            break

if __name__ == "__main__":
    tag = sys.argv[1] if len(sys.argv) > 1 else "consumer"
    main(tag)

这里read_exact是个关键函数。read调用返回的字节数不保证等于请求的字节数，可能一次只返回一部分，所以在需要读完整定长内容时，必须循环读直到凑够为止。这算是所有流式I/O编程里的基础素养，不只是命名管道，Socket编程里同样适用。

还有一个需要留意的点：open(FIFO_PATH, "rb")会阻塞直到写端也打开。所以正确的启动顺序是先启动消费者，再启动生产者。如果你反过来，生产者启动时会卡在open那里，看起来像程序挂死了，实际上是在等消费者出现。这一点我踩过坑，后面单独讲。

3.3 运行验证与退出清理

三个终端分别运行：

bash复制python3 consumer.py display
python3 consumer.py audit
python3 producer.py

正常输出如下：

code复制[display] got seq=0 level=0
[audit]   got seq=0 level=0
[display] got seq=1 level=1
[audit]   got seq=1 level=1

每个消费者都能独立收到完整消息流。这里验证了命名管道一个很舒服的特性：多个读端打开同一个FIFO，每个读端都能看到一份完整的数据副本，而不是把数据瓜分掉。很多人一听说"多个进程读同一个管道"，第一反应是数据会被分流，实际上FIFO的行为是广播式的。这与消息队列的行为完全不同，消息队列是你抢一条我就没了，FIFO是各读各的。

退出时注意清理。直接按Ctrl+C退出消费者不删FIFO文件，下次启动mkfifo会因文件存在而跳过，逻辑上没问题。但如果改天你想彻底重来，最好先把残留的FIFO文件删掉：

bash复制rm -f /tmp/event_pipe.fifo

在你自己的程序里也可以做幂等清理：启动时先尝试删除旧FIFO，再创建新的。不过要小心，如果别的进程正开着旧管道，删除文件并不会影响已经打开的文件描述符，数据照常流动，但新的进程就找不到了。所以在做滚动升级时要小心这个行为。

4. Windows命名管道：命名空间、消息模式与.NET中的落地写法

4.1 Win32命名管道和Linux FIFO的核心差异

如果你主要在Windows上做开发，命名管道的形态和Linux差别挺大。首先名字格式就不一样，Windows的管道路径是\\.\pipe\开头，比如\\.\pipe\event_pipe，它存在于自己独立的命名空间里，不走文件系统，所以没有"文件残留"的问题。

更大的差别在于通信模式。Windows命名管道有两种模式：字节流模式（类似Linux FIFO）和消息模式。消息模式天然维护消息边界：写入端每次WriteFile写入的内容作为一个完整消息，读取端用ReadFile读取时会自动按消息边界返回。也就是说，Windows下你不需要自己设计"长度前缀+内容"这种协议，系统帮你把边界处理好了，这一点比Linux省事不少。

另一个特点是实例概念。Windows命名管道有"实例数"的限制，一个服务端可以创建多个实例，每个实例对应一个客户端连接。这背后的逻辑更接近Socket的listen/accept模型，而不是Linux那种"文件挂出去、谁都能打开"的模式。你可以用CreateNamedPipe指定实例数量（PIPE_UNLIMITED_INSTANCES），然后循环等待客户端连接。这和TCP服务器处理多客户端的方式神似。

4.2 一个跨进程通信的最小实现

Windows下面用.NET/C#写命名管道非常简单，官方库已经封装到很好用的程度。我给出一个服务端和客户端的极简骨架。

服务端：

csharp复制using System;
using System.IO.Pipes;
using System.Text;
using System.Threading.Tasks;

class PipeServer
{
    static async Task Main()
    {
        string pipeName = "event_pipe";
        Console.WriteLine($"[server] wait client, pipe={pipeName}");
        
        while (true)
        {
            var server = new NamedPipeServerStream(
                pipeName, PipeDirection.In, 1, PipeTransmissionMode.Byte);
            
            await server.WaitForConnectionAsync();
            Console.WriteLine("[server] client connected");
            
            byte[] buffer = new byte[4096];
            int read;
            while ((read = await server.ReadAsync(buffer, 0, buffer.Length)) > 0)
            {
                string msg = Encoding.UTF8.GetString(buffer, 0, read);
                Console.WriteLine($"[server] recv: {msg}");
            }
            Console.WriteLine("[server] client closed");
            server.Dispose();
        }
    }
}

客户端：

csharp复制using System;
using System.IO.Pipes;
using System.Text;
using System.Threading;

class PipeClient
{
    static async Task Main()
    {
        string pipeName = "event_pipe";
        var client = new NamedPipeClientStream(".", pipeName, PipeDirection.Out);
        
        Console.WriteLine("[client] connect to server...");
        await client.ConnectAsync();
        
        for (int i = 0; i < 10; i++)
        {
            string line = $"message-{i} : current timestamp {DateTimeOffset.Now.ToUnixTimeSeconds()}";
            byte[] data = Encoding.UTF8.GetBytes(line);
            await client.WriteAsync(data, 0, data.Length);
            await client.FlushAsync();
            Console.WriteLine($"[client] sent: {line}");
            Thread.Sleep(1000);
        }
        client.Dispose();
        Console.WriteLine("[client] done");
    }
}

这里需要解释一个容易忽略的设计点。我故意把服务端的方向设成了PipeDirection.In，也就是服务端只收不发；客户端是PipeDirection.Out只发不收。如果你要双向通信，两端都要用PipeDirection.InOut，并各自维护读写逻辑。很多人初学时会误以为NamedPipeServerStream天然双向，实际上方向完全由创建时指定的参数决定。这点和Linux FIFO的单向性其实是异曲同工，只是Windows的接口给了你更明确的配置入口，更像Socket的语义。

4.3 多客户端并发时的注意点

Windows命名管道服务端处理多客户端，核心模式是"每实例一线程"或者用异步等待。我上面写的循环是单线程串行处理：接受一个客户端，读完它所有消息，断开，再等下一个。这适合顺序请求类场景，但如果你希望多个客户端同时连接，就必须为每个连接单独创建一个NamedPipeServerStream实例，每个实例调用WaitForConnectionAsync，通常配合Task.WhenAll或者线程池来管理。

这个点务必注意：一个NamedPipeServerStream实例同时只能服务一个客户端连接。想要并行服务多个客户端，就得创建多个实例。这是和Linux FIFO"每个读端各自拿数据"最大不同的地方。Windows管道更像传统CS模型的连接，而Linux FIFO更像一对多的广播介质。

另一个Windows特有的坑是PipeTransmissionMode的选择。你用Byte模式时，读端可能像Linux一样出现"半包"问题——数据流没有天然边界。如果你改用Message模式，虽然边界由系统处理，但每个ReadFile会按一次写入返回一条消息，如果你的消息超过管道缓冲区大小，可能触发异常或截断。所以消息模式下最好控制单条消息不要太大。

5. 我踩过的坑：打开假死、空读误解与残留文件

5.1 打开顺序导致的双端互相等待

这是我第一周用FIFO就遇到的事。当时我在一个服务里同时创建了读写两个线程，读写线程各自去open一个FIFO，结果服务启动后直接卡死，没有任何日志输出。查了半天才反应过来——读线程open阻塞等待写端，写线程open阻塞等待读端，两个线程都在等对方先打开，于是形成死锁。

解决方案有两个。最直接的是在启动顺序上保证先开读端再开写端：启动时用一个全局初始化阶段把FIFO读端全部打开，所有生产者在初始化完之后再打开写端。第二个方案是用O_RDWR模式打开管道——读写端共用一个文件描述符，这样open不会阻塞，因为打开动作本身就同时满足了读和写的"对端"条件。但O_RDWR模式有副作用：内核认为两端都是同一个进程，在某些版本的内核行为下，写入的数据可能马上被自己读走，语义会变得混乱。所以我建议能控制启动顺序就控制启动顺序，O_RDWR只作为排查手段，不作为日常使用。

如果你用非阻塞模式open，还有一种方案：open前先以非阻塞方式试探，失败就重试直到成功。但这代码复杂度上来了，不如把初始化顺序理顺。

5.2 read返回0的两种含义，千万别混淆

管道读端的read返回0通常表示写端已关闭。这是EOF信号，意味着管道里不会再有新数据了。但不少同学会把"返回0"当作"读完了这一批数据"，然后傻傻地继续read，结果忙等或空转。

我见过的最严重案例是：消费者进程收到0后没有退出，而是继续循环read，结果该进程占满一个CPU核一直在空转。原因是FIFO读端在写端关闭后返回0，但如果迟迟没有关闭读端，内核会认为管道仍可读——不对，准确说是没有数据，阻塞模式下会一直阻塞，非阻塞模式下会返回EAGAIN。问题通常出在非阻塞模式下返回0和返回EAGAIN没区分，被当成了正常空读。处理规则很简单：返回0就是EOF，进程该清理退出了；非阻塞模式下返回负EAGAIN才是"暂时没数据，等会儿再来"。

5.3 数据边界问题：即使小包原子，也要自己定协议

前面说了，小于PIPE_BUF的写入是原子的，但这只保证"一次写入不被拆散"，不保证"两次写入不被合并"。举个例子，写端分别写了<hdr>A</hdr>和<hdr>B</hdr>两个消息，理论上你希望读端先收到A再收到B。但实际运行中，如果管道缓冲区在第一次写入后立即有空间，内核可能把两次写入的数据合并放在缓冲区里，读端一次read可能同时读走A+B。

这种情况在低流量时尤其容易发生——写端写完A后，读端调度还没开始，写端又写完B了，缓冲区里两段数据连在一起。所以应用层必须自己定义消息边界。我惯用的方案就是长度前缀，写端先写4字节长度，再写消息体；读端先读4字节，知道长度后再读那么长的消息体。这套方案在各类流式传输中都通吃，从TCP到FIFO再到串口，几乎万能。

5.4 文件残留与权限问题

FIFO文件创建后不会自动删除，哪怕所有进程都退出了，/tmp/event_pipe.fifo还在那里。程序里要处理好初始化和清理。我的习惯是程序启动时尝试unlink旧文件再mkfifo新的，但这带来一个问题：如果旧文件正被另一个进程打开着，unlink后那个进程依然能读写，而你新建的文件实际已经是一个全新的管道，两边其实不在一个管道上了。所以稳妥做法是不要用固定路径，用PID或者启动时间戳作为管道路径的一部分，旧进程退出后自然不会再干扰新进程。

权限方面也很容易踩坑。FIFO创建时受umask影响，默认创建的权限是0666 & ~umask，通常出来是0644。如果你的写进程和读进程不是同一个Linux用户，那个0644就会导致写端打不开——因为写需要写权限，而0644对"其他用户"只有读权限。这症状很隐蔽，写端open成功但write报EACCES权限错误。排查时记得看一眼ls -l的权限位，必要时用os.chmod(path, 0o666)显式放开。在生产环境，我还会用setfacl精确控制哪些用户能读写，比全局0o666安全。

5.5 管道缓冲区满导致生产者卡顿

高吞吐场景下，如果消费者处理慢，管道缓冲区写满，生产者会阻塞在write调用上。这看起来像程序卡死了，但其实是内核在行使它的流控职责。大多数时候这是合理的——生产慢点总比丢数据好。但有一种情况是灾难性的：消费者进程崩溃了，写端还孜孜不倦地写一个再也没人读的管道，缓冲区满了就阻塞，最后整个业务链路被拖住。

处理这类问题的套路是给写端加上"松绑"机制。独立线程里执行写入，配合超时或非阻塞模式。Linux下可以设置O_NONBLOCK后写，遇到EAGAIN就把消息丢进一个有界队列或直接丢弃并计数报警，绝不能让业务主流程干等。我个人用的策略是三级降级：先尝试阻塞写，超过阈值自动切非阻塞写，再不行就降级为丢消息并上报指标。宁可少传几条告警，也不能让整个采集管道全部停摆。

6. 选型建议：什么场景用命名管道，什么场景换共享内存或Socket

6.1 四种常见IPC的横向对比

如果你的需求只是"单机两个进程传小消息、频率不高、希望代码简单"，命名管道几乎是最佳选择。但如果你的场景是高频大流量数据传输，比如视频帧、传感器高频波形数据，命名管道的性能就有点跟不上了。它每次读写都要经过内核态和用户态的两次拷贝，缓冲区还要加锁，吞吐量天花板明显低于共享内存。

我把常见IPC手段做了一张对比表，方便你快速判断：

顺带提一个容易混淆的点：匿名管道（pipe()）和命名管道最大的区别在于，匿名管道只能在父子进程间用，通过fork继承文件描述符才能传递，管道的"名字"也就是那个文件描述符本身；命名管道则不需要血缘关系，任何两个进程只要知道文件名都可以建立联系。所以凡是需要解耦进程创建关系的，必须用命名管道。

6.2 我个人的选型判断框架

在单机范围内选择通信方式，我总结了一套非常直白的判断流程，每次都是这么走：

• 消息量不大（每秒几千条以内）、对延迟不敏感、看重代码可维护性，首选命名管道。它胜在接口简单，出错面小，加个协议封装就能上线。
• 双方都是C/C++写的高频实时模块，数据量动辄几十MB每秒，用共享内存加无锁环形队列或信号量。命名管道在这里会成为瓶颈，因为每次read/write都是一次系统调用扎到内核里。
• 需要请求-应答语义、带复杂错误处理、可能跨主机，直接用Socket。命名管道虽然也能做应答，但它的半双工、单方向特性让请求应答写起来别扭。
• 需要广播分发到多个消费者，命名管道非常合适。共享内存做多消费者分发你得自己实现引用计数和读锁，管道帮你做了。

有一个很重要的建议：不要在引入框架之前自己造轮子。不少开源的进程间通信库其实底层就是命名管道加JSON协议，比如一些老的插件系统、监控代理之间的通信。你直接用命名管道加一个统一的序列化层，代码量往往比引入一个完整通信库还少，而且更可控。我见过很多项目为了追求"正式"，一上来就上消息中间件，结果运维成本和资源开销比需求本身还大。先问自己一句：这个需求是不是只需要两个进程在本机说说话？如果是，命名管道大概率够用。

6.3 边界场景：高可靠与超大数据量

高可靠场景里命名管道有个天生弱点：数据只在内核缓冲区里，没有任何持久化。进程写完数据，在消费者读到之前如果内核崩溃或机器断电，数据直接消失。如果要可靠落盘，还是要引入日志文件、数据库或者持久化消息队列。

超大数据量场景我建议绕开。虽然可以通过fcntl(F_SETPIPE_SZ)把管道缓冲区调大，比如调到1MB，但一次write复制1MB数据到内核再复制到读端，两趟拷贝的时间和CPU开销都不可小觑。相比之下，共享内存加mmap可以做到真正的一次拷贝，甚至零拷贝（配合vmsplice这类技巧）。所以在视频推流、图像处理、大数据包的模块间传递里，我基本不用管道。

另外提醒一下有跨核通信需求的同学。如果你在多核CPU上做核间通信优化，比如把事件从核0的线程送到核2的线程，用命名管道意味着每次都要走内核调度和系统调用，锁竞争跨核放大，延迟会显著增加。这种场景务必要考虑无锁队列或Linux的io_uring方案。命名管道在跨核场景下往往不是最优解，但它足够简单，如果延迟指标要求不高，依然可以轻松跑通。

最后再分享一点体感上的东西

道理讲完了，说点实际的。我在生产环境用命名管道维护过一条持续运行了两年的告警通道，期间只出过两次故障，一次是上一篇讲到的权限问题，另一次是消费者进程升级时旧管道文件没清理、新消费者打开的是新文件，两边断链。解决手段都是运维层面的规范问题，代码本身一直很稳。

如果你现在正在为两个进程的通信方案发愁，我建议先花十分钟把命名管道的Demo跑起来，用最小的代价验证它能不能满足你的需求。很多时候最简单的方案反而是最好维护的方案，而"用什么大厂中间件"这种纠结，很多时候只是想多了。管道这个几十年前就有的机制，在今天的云原生、微服务主旋律下，仍有它的立足之地，尤其是在嵌入式网关、边缘采集设备这类单机小进程扎堆的环境里。它就像工具箱里的那把最普通的一字螺丝刀——不够酷，但你在关键时刻会庆幸手边有它。