unix domain socket服务端需用绝对路径绑定，确保父目录存在且可写，路径≤108字节；客户端路径须字节级一致；流式通信需自定义消息协议防粘包；关闭后须显式os.remove清理socket文件。
用 net.ListenUnix 启动服务端时权限或路径错误
Unix Domain Socket 的服务端绑定路径必须是文件系统上可写的、长度不超过 108 字节（Linux）的绝对路径，且父目录得存在。常见错误是直接写 /tmp/mysock 却没确保 /tmp 可写，或路径含非法字符（如空格、控制符），或重复启动导致 bind: address already in use。
- 先
os.RemoveAll("/tmp/mysock")清理残留 socket 文件再监听 - 用
filepath.Abs规范路径，避免相对路径引发的不可预测行为 - 监听前检查父目录权限：
os.Stat(filepath.Dir(sockPath))+os.IsNotExist - 错误信息
listen unix /tmp/mysock: bind: invalid argument多半是路径超长或含非法字符
net.DialUnix 连接失败的典型原因
客户端调用 net.DialUnix 失败，90% 是因为服务端还没就绪、socket 文件不存在、或路径不一致——客户端和服务端用的路径字符串必须字节级完全相同，包括结尾是否带 \x00（仅在 AF_UNIX 的 sun_path 截断场景下才敏感，Go 标准库已封装，一般不用管）。
- 别用
net.Dial("unix", "/tmp/mysock")—— 它底层调的是net.DialUnix，但容易忽略地址类型；显式用&net.UnixAddr{Net: "unix", Name: "/tmp/mysock"}更可控 - 连接前加简单重试逻辑，比如循环 3 次，每次
time.Sleep(10 * time.Millisecond)，避免竞态 - 错误
dial unix /tmp/mysock: connect: no such file or directory表示服务端根本没成功 bind，不是客户端问题
读写数据时阻塞或粘包怎么处理
Unix Domain Socket 默认是流式（SOCK_STREAM），和 TCP 一样无消息边界，不自己加协议就会粘包。标准库 net.Conn 接口不提供“按消息收发”能力，得自己约定格式。
- 最简方案：每条消息前加 4 字节大端长度（
binary.Write(conn, binary.BigEndian, uint32(len(data)))），接收方先读 4 字节再读对应长度 - 别用
conn.Read([]byte)直接读满缓冲区——它可能只读到部分消息，得配合io.ReadFull或循环读 - 如果选
SOCK_DGRAM（通过net.ListenUnixgram），能天然保消息边界，但不保证送达，且 Go 中需手动管理地址（*net.UnixAddr），调试更麻烦 - 注意
conn.SetDeadline对 Unix socket 有效，可防死锁，但SetReadDeadline在 Linux 上实际精度受限于系统定时器
关闭连接后 socket 文件残留怎么办
服务端 listener.Close() 不会自动删 socket 文件，下次启动会因文件已存在而失败。这不是 bug，是 Unix socket 的设计特性——文件只是地址载体，内核靠 inode 关联连接，文件本身可删可留。
- 务必在
listener.Close()后显式os.Remove(sockPath) - 更健壮的做法：用
defer os.Remove(sockPath)包裹整个服务生命周期，哪怕 panic 也能清理 - 如果进程崩溃未清理，下次启动前检测
os.Stat(sockPath)，若存在且不是被占用的 socket（可用net.ListenUnix尝试 bind 判断），再删 - 别依赖
syscall.Unlink或os.Chmod去“释放”，Unix socket 文件没被内核引用后，os.Remove就够了
事情说清了就结束。真正难的不是写通一次，而是处理服务启停时的竞态、不同用户权限下的路径访问、以及和 systemd socket activation 集成时的地址复用——那些得看具体部署环境。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
