Unix Socket是Docker本地通信首选，通过挂载/var/run/docker.sock实现容器与守护进程高效安全交互，零网络开销且依赖文件权限控制；而容器间通信应优先使用TCP socket配合用户自定义网络。
Docker 容器本身不直接“通过 Socket 进行进程间通信（IPC）”，而是依赖底层 Linux 的 IPC 机制，其中 Unix socket 是一种高效、安全的本地通信方式。容器内进程若需与宿主机上的 Docker 守护进程通信（比如调用 API 创建新容器），或容器之间需要低延迟、免网络栈的通信，Unix socket 就是关键路径之一。
docker.sock：容器访问 Docker 守护进程的入口
宿主机上默认存在一个 Unix socket 文件：/var/run/docker.sock。它是 Docker daemon 监听的本地通信端点，权限严格（通常属 root:docker，仅 docker 组可读写）。容器若挂载该 socket，就能像本地客户端一样调用 Docker API：
- 启动容器时加参数：
-v /var/run/docker.sock:/var/run/docker.sock:ro（只读更安全）或:rw（需写权限时） - 容器内可用 curl 或 docker CLI 工具（如安装了 docker-cli）直接请求：
curl --unix-socket /var/run/docker.sock http://localhost/containers/json - 常见用途包括 CI/CD 构建镜像、动态启停兄弟容器、监控容器状态等
容器间使用 Unix socket 通信的限制与替代方案
Unix socket 本质是文件系统级 IPC，**不能跨容器直接使用**——因为每个容器有独立的 mount namespace 和文件系统视图。你无法让 Container A 的进程直接 connect 到 Container B 的某个 /tmp/app.sock，除非显式共享同一挂载卷且路径一致，但这违背容器隔离原则，也不可靠。
真正实用的容器间通信方式是：
-
基于用户自定义桥接网络（user-defined bridge）：容器加入同一 network 后，可通过容器名自动 DNS 解析，用 TCP/UDP socket 通信（如
http://redis:6379） -
共享 host 网络命名空间（--network=host）：容器直接使用宿主机网络栈，此时可监听
127.0.0.1:port并被同主机其他进程访问（含其他 host-network 模式容器） -
使用命名管道或共享内存需额外配置：例如通过
--ipc=container:<name>共享 IPC namespace，再配合 tmpfs 卷放置 socket 文件
何时该用 TCP socket 而非 Unix socket
绝大多数容器间服务调用场景应优先选择 TCP socket（即普通网络端口），原因很实际：
- 天然支持跨主机通信（配合 overlay 网络或 service mesh）
- 无需处理文件路径挂载、权限、namespace 隔离等复杂问题
- 与应用框架兼容性好（Spring Boot、Node.js、Python Flask 等默认监听 TCP）
- Docker 内置 DNS + user-defined network 提供稳定的容器名解析，IP 变化完全透明
简单验证：在容器里访问 docker.sock
快速测试是否成功挂载并可用：
（在已挂载 /var/run/docker.sock 的容器中执行）- 检查 socket 是否存在且可访问：
ls -l /var/run/docker.sock - 用 curl 查询容器列表：
curl -s --unix-socket /var/run/docker.sock http://localhost/containers/json | jq '.[0].Names' - 注意：若返回 403 或 connection refused，通常是权限不足或 daemon 未运行
