go中unix.sendmsg传文件描述符失败的根本原因是sock_cloexec标志导致fd被内核自动关闭，需手动创建socket并清除该标志，发送时正确设置scm_rights cmsg，接收后立即dup并转为*os.file。
Go 中 unix.Sendmsg 传文件描述符为什么总失败？
根本原因不是代码写错了，而是没关掉 SOCK_CLOEXEC —— Go 的 unix.Socket 默认带这个 flag，子进程或对端 recvmsg 时 fd 一进来就被内核自动 close 掉了。
实操上必须显式去掉：
- 用
unix.Socket(unix.AF_UNIX, unix.SOCK_STREAM, 0, unix.SYS_SOCKET)手动创建 socket，不走net.ListenUnix - 调用
unix.SetNonblock(fd, false)确保阻塞模式（非阻塞下Sendmsg可能部分成功但 fd 未送达） - 发送端填
unix.Cmsghdr时，Level必须是unix.SOL_SOCKET，Type必须是unix.SCM_RIGHTS，错一个就静默丢 fd - 传递的 fd 值本身要有效且可继承：比如用
unix.Dup()复制一次再传，避免原 fd 被上层逻辑 close
接收端用 unix.Recvmsg 拿不到 fd 怎么办？
不是没收到，是 Go runtime 自动帮你 close 了——只要 fd 进入 Go 的文件描述符表（哪怕只在 cmsg 里闪一下），GC 或 goroutine 切换时可能触发 runtime.fdcleaner 清理。
关键动作是「立刻移交控制权」：
立即学习“go语言免费学习笔记（深入）”；
- recvmsg 后立即用
unix.Dup(fd)复制一份，拿到新 fd 号 - 立刻调用
unix.Close(fd)关掉原始 cmsg 里的 fd（别等 defer） - 新 fd 要绑定到 Go 的
*os.File：用os.NewFile(uintptr(newFD), "fd-passed")，否则后续读写会 panic - 注意：
Recvmsg返回的oob数据长度必须 >=unix.SizeofCmsghdr + 4（一个 int32），否则说明 cmsg 根本没附带 fd
SCM_RIGHTS 能传哪些 fd？有啥限制？
能传，但不是所有 fd 都“有用”。内核只负责复制句柄，不校验语义。
典型可用场景和陷阱：
- 普通文件
open()得到的 fd ✅，但对方用os.NewFile打开后，偏移量是 0，不是发送方当前 offset - 监听 socket（如
net.Listener底层 fd）✅，可用于热重启；但要注意对方是否已 setsockopt（如SO_REUSEPORT） - 管道、eventfd、timerfd ✅，但需双方约定协议，Go stdlib 不直接支持这些类型
- 不能传
stdin/stdout/stderr（1/2/3）❌：多数情况下它们被标记为CLOEXEC，dup 失败；即便成功，对方也拿不到终端控制权 - 跨用户进程传 fd ❌：Linux 要求 sender 和 receiver uid 相同，否则 recvmsg 返回
EACCES
用 net.UnixConn 能绕过手动 sendmsg 吗？
不能。标准库的 net.UnixConn 完全屏蔽了 cmsg 机制，Write/Read 只走数据通道，SetDeadline 之类还会干扰底层 fd 状态。
如果非要走 net 包，唯一办法是自己封装：
- 用
net.FileConn从 listener 拿出底层*os.File，再用file.Fd()提取 raw fd - 用
unix.Recvmsg/unix.Sendmsg直接操作该 fd，完全绕过 net.Conn 的缓冲和状态机 - 注意：一旦这样干，就不能再对这个 conn 调用任何
net.Conn方法（比如Close()会 double-close） - 性能上其实没损失：系统调用次数一样，只是少了 Go runtime 的额外拷贝和锁竞争
真正麻烦的从来不是怎么传，是怎么确保对方进程在 fd 到达瞬间还没 exit、没删掉临时 socket 路径、没把目标 fd 表填满——这些没法靠代码 fix，得靠超时、重试和进程生命周期协同。
