优先使用自定义bridge网络+容器名解析，这是单机多容器通信最稳妥方式；默认bridge不支持服务名解析，必须创建自定义网络启用docker内置dns，容器重启后名称不变、通信不受影响。
直接用 Docker Socket 实现“容器通信”是典型误用，既不高效也不安全。真正高效的互访通信，靠的是合理设计网络接口——核心在于选对网络模式、建好自定义网络、用好内置 DNS，而不是绕路挂载 /var/run/docker.sock。
优先使用自定义 bridge 网络 + 容器名解析
这是单机多容器通信最稳妥、最常用的方式。默认 bridge 网络不支持服务名自动解析，必须创建自定义网络才能启用 Docker 内置 DNS。
- 执行
docker network create app-net创建独立网段 - 启动容器时统一指定
--network app-net，例如：docker run -d --name api --network app-net nginxdocker run -it --name client --network app-net curlimages/curl - 在 client 容器中直接执行
curl http://api或ping api，Docker 自动完成名称到 IP 的映射 - 容器重启或重建后，名称不变，通信不受影响，无需硬编码 IP
跨主机通信选 overlay 或第三方插件
当容器分散在不同物理机或虚拟机上时，bridge 网络无法跨节点直连，需借助支持服务发现的分布式网络方案。
- 使用 Docker Swarm：先
docker swarm init，再docker network create -d overlay my-overlay，服务自动注册并可跨节点通过服务名访问 - Kubernetes 场景下，直接依赖 Service 对象和 ClusterIP，Pod 之间通过
service-name.namespace.svc.cluster.local互通 - 若不用编排平台，可选用 Cilium、Calico 等 CNI 插件，提供更细粒度策略与可观测性
避免常见陷阱：别碰 Docker Socket 做通信
Docker Socket（/var/run/docker.sock）本质是管理通道，不是数据通道。挂载它等于赋予容器宿主机 root 级控制权。
- 容器一旦被攻破，攻击者可调用
docker exec、docker rm等命令，接管全部容器甚至宿主机 - 它无法替代 HTTP、gRPC、消息队列等应用层通信机制，延迟高、无重试、无超时、无鉴权
- 仅限极少数运维工具（如构建镜像的 CI Agent、采集指标的 cAdvisor）在严格加固前提下使用（只读挂载 + 非 root 用户 + 能力裁剪）
需要触发动作？走标准应用协议
如果业务逻辑要求“A 容器通知 B 容器做某事”，这不是网络配置问题，而是架构设计问题。
- B 容器暴露轻量 HTTP 接口（如
POST /reload），A 容器发起请求即可 - 引入 Redis Pub/Sub 或 RabbitMQ，A 发布事件，B 订阅处理，解耦且可靠
- 共享挂载卷 + 文件变更监听（如 inotifywait），适合配置热更新等低频同步场景
