AF_UNIX是POSIX特性，Windows原生不支持；跨平台需条件编译：Linux/macOS用AF_UNIX路径绑定，Windows用命名管道或回环TCP，二者语义不同且无文件描述符传递能力。
Unix域套接字在Windows上根本不存在
直接说结论：AF_UNIX 是 POSIX 特性，Windows 原生不支持。所谓“跨平台创建 AF_UNIX socket”，本质是「在支持的系统上用标准方式做，在 Windows 上绕过去」——不是封装出一个统一接口，而是条件编译 + 替代方案。
常见错误现象：socket(AF_UNIX, SOCK_STREAM, 0) 在 MinGW/MSVC 下编译失败（AF_UNIX 未定义），或运行时报 WSAENOPROTOOPT / EAFNOSUPPORT；有人强行用 AF_INET 绑定 127.0.0.1 冒充 Unix 域套接字，结果暴露端口、丢失文件权限控制、无法传递文件描述符。
- Linux/macOS：用
AF_UNIX，路径绑定，权限由文件系统控制 - Windows：只能用命名管道（
CreateNamedPipeA）或本地回环 TCP（AF_INET+127.0.0.1），二者语义和能力完全不同 - 若需传递文件描述符（如 Linux 的
SCM_RIGHTS），Windows 完全无对应机制，必须重构通信协议
如何写可编译的跨平台 socket 创建函数
核心是预处理器隔离 + 接口抽象。不要试图让 Windows “假装”有 AF_UNIX，而是提供一致的高层行为（如“本地进程间连接”），底层分治。
示例关键点：
立即学习“C++免费学习笔记（深入）”；
- 用
#ifdef __linux__/#ifdef __APPLE__区分 Unix 类系统，#ifdef _WIN32处理 Windows - Unix 路径长度限制严格（
sizeof(sockaddr_un.sun_path)通常为 108 字节），Windows 命名管道名格式为\\.\pipe\xxx，不能混用字符串处理逻辑 - Unix 域套接字文件需要显式
unlink()清理，Windows 命名管道自动销毁，但残留句柄可能导致下次创建失败 - 返回类型建议统一用自定义句柄（如
struct ipc_handle），而非裸int或HANDLE，避免调用方误用close()/CloseHandle()
简短示意：
#ifdef _WIN32
HANDLE hPipe = CreateNamedPipeA("\\.\pipe\myapp", ...);
// 后续用 ConnectNamedPipe / ReadFile / WriteFile
#else
int sock = socket(AF_UNIX, SOCK_STREAM, 0);
struct sockaddr_un addr = {};
addr.sun_family = AF_UNIX;
strncpy(addr.sun_path, "/tmp/myapp.sock", sizeof(addr.sun_path) - 1);
bind(sock, (struct sockaddr*)&addr, offsetof(struct sockaddr_un, sun_path) + strlen(addr.sun_path));
#endif
AF_UNIX 路径安全与清理的坑
Unix 域套接字本质是文件系统中的特殊文件，权限和生命周期管理极易出错。
-
bind()失败常见原因是路径已存在且非 socket 类型，或父目录无写权限 —— 必须先unlink()，但要检查errno == ENOENT避免误删其他文件 - 服务进程崩溃后 socket 文件残留，导致下次启动失败；不能简单
unlink()所有路径，应结合stat()检查st_mode & S_IFSOCK - 路径过长（>108 字节）在不同 libc 表现不一：glibc 截断不报错，musl 直接
EINVAL；建议限制总长 ≤ 90 字节并用sizeof(addr.sun_path)计算实际长度 - macOS 对
AF_UNIX路径支持较弱，推荐用/var/tmp/而非/tmp/（后者可能被 tmpfs 挂载，不支持 socket 文件）
Windows 上命名管道 vs 回环 TCP 怎么选
没有银弹。选哪个取决于你真正需要什么能力。
- 需要双向流式通信、低延迟、类似 Unix 域套接字体验 → 用命名管道（
CreateNamedPipeA），但注意它不支持select()，得用完成端口或重叠 I/O - 已有基于
socket的代码，不想大改 → 用AF_INET+127.0.0.1，但必须加端口随机化（bind(..., port=0)）和防火墙白名单，且无法限制仅本机用户访问（靠 OS 用户隔离） - 需要传输大量数据且对吞吐敏感 → 命名管道通常比 loopback TCP 快 10%~30%，因绕过 TCP/IP 栈
- 调试困难：命名管道在资源监视器里看不到连接状态，而
netstat -an | findstr :port可查 loopback 连接
复杂点在于：Unix 域套接字的“连接即认证”（文件权限控制谁可连）在 Windows 上没有直接等价物。命名管道虽支持 DACL，但配置麻烦；loopback TCP 则完全不提供该能力。这点常被忽略，直到上线后被本地恶意进程打穿。
