应使用os.Stat获取文件信息后，通过fi.Mode() & os.ModeSocket != 0判断是否为套接字，因该模式位仅Unix-like系统支持且需按位与检测，不能直接比较或依赖内容嗅探。
如何用 os.Stat 判断文件是否为套接字
Go 语言中判断一个路径是否指向套接字（socket），核心是通过 os.Stat 获取文件元信息，再检查其模式位是否包含 os.ModeSocket。这不是靠扩展名或内容嗅探，而是直接读取 inode 的类型标识，准确且跨平台（Linux/macOS 支持，Windows 不支持套接字文件）。
常见错误是把 os.ModeSocket 当作布尔值直接比较，或者忽略 os.Stat 可能失败的前提：
-
os.Stat返回的fs.FileInfo必须非 nil 才能调用Mode()，否则 panic - 套接字只存在于 Unix-like 系统（如 /var/run/docker.sock），Windows 上该模式位恒为 false
- 必须用按位与：
fi.Mode() & os.ModeSocket != 0，不能写成fi.Mode() == os.ModeSocket
示例代码片段：
f, err := os.Stat("/var/run/docker.sock")
if err != nil {
// 文件不存在、无权限等
return false
}
return f.Mode()&os.ModeSocket != 0
为什么不能用 http.DetectContentType 或 magic 库判断套接字
http.DetectContentType 作用是推测 MIME 类型，它读前 512 字节做规则匹配，对套接字文件会直接失败——因为套接字不是普通文件，os.Open 会返回 “operation not supported” 类错误，根本走不到内容检测逻辑。
立即学习“go语言免费学习笔记（深入）”；
同理，libmagic 绑定库（如 github.com/rakyll/statik 或 github.com/mholt/caddy/magic）依赖 open(2) + read(2)，而套接字设备不支持常规读取，调用会阻塞或返回 ENXIO/ENOTSOCK。
所以：套接字识别只能走元数据路径（stat(2)），不能走内容路径。这是本质区别，不是精度问题。
套接字文件与普通文件、管道的模式位区分
Unix 文件系统用同一组 mode 位编码多种类型，os.ModeSocket 只是其中之一。实际使用中容易混淆的是它和 os.ModeNamedPipe、os.ModeDevice 的边界：
-
os.ModeSocket：对应S_IFSOCK，路径表现为可 bind/connect 的 AF_UNIX 地址文件 -
os.ModeNamedPipe：对应S_IFIFO，由mkfifo创建，os.Open可读但需两端同时打开 -
os.ModeDevice：对应S_IFBLK或S_IFCHR，如/dev/sda或/dev/tty
它们互斥，但都可能出现在同一目录下（如 /dev）。判断时建议按优先级顺序检查：IsDir() → IsRegular() → & os.ModeSocket → & os.ModeNamedPipe → & os.ModeDevice，避免漏判。
在 Docker 或 systemd 场景下验证套接字路径的注意事项
生产环境常遇到看似是套接字、实则不可用的情况，比如：
- 路径存在但权限不足（
srw-rw----要求用户在 docker 组）→os.Stat成功，但后续net.Dial("unix", path)失败 - 路径是符号链接 →
os.Stat返回目标文件的 mode，os.Lstat才返回链接本身（mode 为os.ModeSymlink） - 容器内挂载的套接字路径被覆盖为普通文件 →
os.Stat返回os.ModeRegular，而非os.ModeSocket
因此，仅靠 os.Stat 判定类型只是第一步；真正要用，还得紧接着尝试 net.Dial("unix", path) 并捕获 syscall.ECONNREFUSED 或 syscall.ENOENT 等具体错误。
