两个golang怎么打开ipc

两个独立的Go进程，如何开启IPC通信？

开门见山，两个Go进程间进行IPC（进程间通信），最常用、最可靠的方式就是使用 net.Listen("unix")。它支持跨语言、高性能，自带连接管理与超时机制。当然，实际使用中得注意socket文件路径的权限、旧文件的清理、读写超时的设置，以及路径长度限制这些细节。

在Go的世界里，没有“打开IPC”这种一键式的抽象操作。你必须明确选择底层的通信机制：Unix Domain Socket（这是推荐的首选）、os.Pipe（仅适用于父子进程）、或者共享内存（这需要动用syscall.mmap并搭配同步原语）。别指望能像在Shell里写cmd1 | cmd2那样，管道就自动建立好了。

用 net.Listen("unix") 建立跨进程通信

这是生产环境中的首选方案。它允许任意两个独立的Go进程（甚至与其他语言编写的进程）进行通信，性能接近内存拷贝，并且天然支持连接管理和超时控制。

• 路径准备是关键：服务端在监听之前，必须确保socket文件所在路径的父目录存在，并且具有可写权限。通常的做法是：os.MkdirAll(filepath.Dir(sockPath), 0755)。
• 清理旧文件是习惯：开始监听后，应立即尝试清理可能残留的旧socket文件：os.Remove(sockPath)（可以忽略os.IsNotExist错误）。
• 超时设置是保险：务必为每一个net.Conn连接设置读写deadline，例如：conn.SetReadDeadline(time.Now().Add(5 * time.Second))。否则，一旦客户端异常退出，服务端可能会陷入永久阻塞。
• 路径长度有上限：socket的路径长度不能超过系统定义的UNIX_PATH_MAX（通常是108字节）。为保险起见，建议将路径控制在64个字符以内，比如/tmp/myapp.sock。
• 连接失败要重试：客户端连接时如果遇到connect: connection refused错误，大概率是服务端还没完成Listen或Accept。这时别急着panic，加上重试逻辑才是稳健的做法。

os.Pipe 只适用于父子进程，且极易卡死

它返回一对*os.File，本质上是内核的管道文件描述符。但请注意，它只在fork产生的父子进程间有效，并非通用的IPC方案，更不是Go channel。

• 句柄管理要精确：父进程调用os.Pipe()获得读写端后，在fork子进程之前，必须关闭子进程不需要的那一端：子进程关闭readEnd，父进程则关闭writeEnd。只要漏关一个写端，读端就永远等不到EOF。
• 优先使用标准方法：当使用exec.Command启动子进程时，优先采用cmd.StdoutPipe()这类方法，它内部已经帮你做好了文件描述符的隔离。不要手动传递os.Pipe的文件描述符，容易出错。
• 复杂管道交给Shell：想要实现多级管道（比如ls | grep | awk）？几乎没人会手动拼接。直接使用exec.Command("sh", "-c", `ls | grep go`)，既省事又健壮。
• 等待子进程退出：子进程退出后，父进程必须调用cmd.Wait()来获取*exec.ExitError。只有通过这个，才能准确判断子进程是正常结束还是异常终止，不能只看err != nil。

别把 channel 当 IPC，也别把 sync.Mutex 跨进程用

这是一个常见的误区。channel是用于goroutine之间通信的，其生命周期绑定于当前进程；而sync.Mutex是线程级的同步原语，两个进程的地址空间完全隔离，彼此根本无法感知对方的状态。

• channel的关闭有讲究：在协程的链式处理（例如 gen → filter → print）中，close(ch)必须由最后一个发送方来执行，并且只能关闭一次。接收方绝对不要去close channel，否则下游的for range ch会立刻死锁。
• 共享内存是系统级操作：如果真想让多个进程共享一块内存区域，需要动用syscall.MemfdCreate配合syscall.Mmap，然后再搭配POSIX信号量（sem_open）或原子操作（atomic.CompareAndSwapUint32）来做同步。Go标准库没有封装这些，需要借助cgo或x/sys/unix包。
• Mutex不能跨进程：试图把sync.Mutex放进mmap映射的内存区域供多个进程使用？这行不通，它会panic。因为Mutex的内部字段包含了runtime的指针，这些指针在另一个进程的地址空间里是无效的。

说到底，使用Unix domain socket的难点，往往不在于Listen或Dial这两个调用本身，而在于连接生命周期的精细管理：客户端断开连接后没有妥善通知、服务端忘记设置deadline、socket文件路径权限配置错误、旧的socket文件残留未被清理——这些才是线上IPC故障真正的罪魁祸首。

立即学习“go语言免费学习笔记（深入）”；