net.dial 第二个参数必须是 unix socket 文件的绝对路径（如 /tmp/myapp.sock），而非 ip:端口；第一个参数必须为 "unix"，不可写成 "unix://" 或 "unixgram"；常见故障根源是文件不存在、权限不足或服务未监听。
net.Dial 第二个参数要传 socket 文件路径，不是地址加端口
Unix Domain Socket 没有 IP 和端口概念，net.Dial 的第二个参数必须是文件系统路径（如 /tmp/myapp.sock），不能写成 127.0.0.1:8080 这类 TCP 格式。传错会直接报 dial unix /tmp/myapp.sock: connect: no such file or directory 或 connection refused —— 前者多半是路径不存在或权限不对，后者更可能是服务没启动或 socket 文件残留未清理。
实操建议：
- 确认 socket 文件真实存在：
ls -l /path/to/socket.sock，注意文件权限是否允许当前用户读写 - 连接时用绝对路径，避免相对路径引发的 cwd 依赖问题
- 如果服务由 systemd 管理，socket 可能位于
/run/xxx.sock，需确认目录可访问且 SELinux/AppArmor 未拦截
第一个参数必须是 "unix"，不是 "unixgram" 或 "unixpacket"
net.Dial 第一个参数指定网络类型，Unix Domain Socket 的流式通信（类似 TCP）对应 "unix"；"unixgram" 是无连接数据报（类似 UDP），"unixpacket" 支持消息边界但极少用。绝大多数场景（如 Docker、containerd、自研 daemon）都走 "unix"。
常见错误：
- 误写成
"unix://"或"unix://path"→ 报unknown network unix:// - 用
"unixgram"去连本应是流式的服务 → 连接成功但后续Write失败，或服务端收不到完整数据 - Go 1.19+ 对网络名校验更严格，非法值会 panic，不再静默 fallback
正确调用示例：
conn, err := net.Dial("unix", "/var/run/docker.sock", nil)
连接失败时优先检查 socket 文件状态而非 Go 代码逻辑
Unix socket 的典型故障和 TCP 完全不同：没有“端口被占”“防火墙拦截”，只有三类根源——文件不存在、权限不足、服务未监听。Go 层面的 net.Dial 错误信息往往模糊（比如统一报 connect: connection refused），容易误导排查方向。
快速验证步骤：
- 用
nc -U /path/to.sock测试能否手动连通（需安装netcat） - 用
sudo ss -lpx | grep sock看内核是否已绑定该路径（ss输出中要有u_str类型） - 检查 socket 文件是否为“套接字类型”：
file /path/to.sock应输出socket，而非regular file - 若服务刚重启，旧 socket 文件可能残留，需先
rm再启服务（有些服务不自动清理）
客户端无需显式设置 timeout，但服务端 accept 超时会影响首次连接体验
net.Dial 默认无超时，阻塞直到连接建立或系统级错误（如 ENOENT）。你可以传入 &net.Dialer{Timeout: 5 * time.Second} 控制最大等待时间，但这只影响“发起连接”的阶段；真正的瓶颈常在服务端：如果服务进程卡在初始化、或 listen() 后迟迟不 accept()，客户端就会卡满 timeout 时间。
所以实际部署中要注意：
- 不要依赖
Dial超时来判断服务健康——它反映的是“能不能触达 socket 文件”，不是“服务是否就绪” - 关键服务建议加一层健康检查，比如连上后发个
PING请求并等待响应 - socket 文件路径最好带版本号或哈希（如
/run/myapp.v2.sock），避免新旧服务混用导致协议不兼容
Unix domain socket 的坑不在 Go 语法，而在文件系统语义和服务生命周期管理。路径、权限、残留文件这三样，比 net.Dial 参数本身更容易让人花两小时找 bug。
