子进程写os.pipe卡住因父进程未关闭冗余写端；sync.mutex不能跨进程同步；unix socket连不上常因服务端未就绪或路径权限问题；子进程异常需通过exec.exiterror判断并及时wait清理。
Go 里用 os.Pipe 做父子进程通信，为啥子进程一写就卡住？
因为 os.Pipe 返回的 *os.File 是阻塞式 I/O，且父子进程共享文件描述符副本，但没关掉冗余句柄时，读端会等“所有写端关闭”才 EOF——哪怕只一个子进程在写，父进程不关自己的写端，读就会永远挂起。
- 父进程 fork 前创建 pipe，fork 后：父进程关掉
writeFD，只保留readFD；子进程关掉readFD，只保留writeFD - 务必用
syscall.Close或file.Close()显式关闭不需要的端，不能依赖 GC - 如果用
exec.Command启动子进程，优先走cmd.Stdin/Stdout管道，它内部已帮你做了句柄隔离
sync.Mutex 能不能跨进程保护共享内存？
不能。sync.Mutex 是线程级原语，只在单个进程地址空间内有效；两个独立进程的 goroutine 不共享内存页，更不共享 mutex 内部的 futex 或 NT 内核对象。
- 跨进程同步必须用 OS 提供的 IPC 原语：Linux 用
sem_open/sem_wait（POSIX 信号量），或shm_open+mmap+自旋锁+atomic.CompareAndSwapUint32 - Go 标准库不封装 POSIX sem/shm，得用
cgo调syscall，或直接上github.com/edsrzf/mmap-go+golang.org/x/sys/unix - 别试图把
sync.Mutex放到 mmap 区域里——它的字段含指针和 runtime 内部状态，跨进程无效且大概率 panic
用 net.Listen("unix") 做本地 IPC，为什么连不上还报 connect: connection refused？
常见于服务端还没 bind 完、客户端就 connect，或 socket 文件路径权限/目录不存在，或服务端监听后没调 Accept 导致连接队列满。
- 确保监听前目录存在且可写：
os.MkdirAll(filepath.Dir(sockPath), 0755) - 服务端启动后加小延迟（如
time.Sleep(10 * time.Millisecond)）再让客户端连，或改用重试逻辑 - 客户端 connect 失败时检查错误是否为
syscall.ECONNREFUSED，而不是直接退出——这说明服务端进程活着但没 listen，不是端口占用 - Unix domain socket 路径长度限制为
UNIX_PATH_MAX（通常是 108 字节），超长会静默失败，建议路径控制在 64 字以内
子进程 panic 后父进程怎么知道并清理资源？
靠 cmd.Process.Wait() 或 cmd.Wait() 阻塞等待，它返回的 *exec.ExitError 里含 exit code 和 signal，是唯一可靠判断子进程异常终止的方式。
立即学习“go语言免费学习笔记（深入）”；
- 不要只看
err != nil就认为失败——正常 exit(0) 时cmd.Wait()也返回nil，非零退出码时返回*exec.ExitError - 检查
exitErr.ExitCode()是否非 0，或exitErr.Signal()是否非 nil（表示被 signal 终止） - 若用
syscall.Syscall手动 fork，必须用syscall.Wait4获取子进程状态，否则变成僵尸进程 - 父进程退出前务必确保所有子进程已 wait，否则残留子进程可能继续写 pipe 或占 socket，导致下次启动失败
跨进程同步最麻烦的从来不是怎么实现，而是谁负责 cleanup、什么时候 close fd、以及 error path 下是否漏关资源——这些地方一错，问题往往延后几秒甚至几分钟才暴露。
