是否有任何理由偏爱命名管道而不是本地 IPC（都使用 win-api）、effort-wize、resource-wize 或其他方式的套接字，因为两者的行为非常相似（并且很可能被类似的接口抽象出来），在可能已经将套接字用于网络目的的应用程序中？
我至少可以说出寻址问题：套接字的端口号与管道的文件名。此外，命名管道 (AFAIK) 不会警告防火墙（阻止/解除阻止对话框），尽管被阻止的应用程序仍然可以通过本地套接字进行通信。还有什么要考虑的吗？
在使用套接字的情况下，在本地使用套接字时是否有任何推荐的 winsock 设置/标志？
一些细微的差别：
如果您没有正常工作的适配器，套接字将不适用于本地 IPC。没有正常工作的适配器的 PC 有多常见？好吧，当有人试图在没有插入网络或电源的笔记本电脑上向客户展示我们的软件时（因此操作系统禁用网卡以节省电力）并且无线适配器被禁用（因为笔记本电脑用户没有使用无线）。您可以通过安装环回适配器来解决此问题，但这并不理想。
防火墙软件可能会导致建立 TCP/IP 连接出现问题。这不应该是本地 IPC 的问题，但我不相信。命名管道也可以有防火墙。
由于创建命名管道或创建命名管道的新实例所需的权限，您可能会遇到问题。例如，我正在使用相同的命名管道运行多个服务器（可能不是一个好主意，但这是为了测试）并且在 CreateNamedPipe 中有些失败，因为创建管道的第一台服务器在管理员模式下运行（因为它是从管理员模式下的 Visual Studio），而其余的都是从具有正常 UAC 级别的命令行启动的。
尽管 Rubens 提到的文章主要是关于网络上的 IPC，但它确实指出“本地命名管道在内核模式下运行并且非常快”。
您可能要考虑的另一个解决方案是命名共享内存区域。这有点工作，因为你必须自己建立一个流控制协议，但我过去成功地使用了这个，速度是最重要的。