核心目标是实现服务间可靠、安全、可发现的通信，优先使用支持dns解析的自定义bridge网络；跨主机部署需overlay网络；host模式仅限高性能且低隔离场景；应配合编排工具统一管理，避免硬编码ip。
微服务架构下，Docker 容器网络配置的核心目标是：让服务之间能可靠、安全、可发现地通信，同时便于扩展和运维。关键不在于堆砌技术，而在于选对模式、建好网络、管住通信。
优先用自定义 bridge 网络
默认的 bridge 网络不支持容器名解析，服务间只能靠 IP 通信，极难维护。自定义 bridge 是本地多服务协作的事实标准：
- 创建网络时指定子网和网关，避免与其他网络冲突：
docker network create --driver bridge --subnet 172.20.0.0/16 my-net - 启动容器时显式加入该网络：
docker run -d --name user-svc --network my-net user-service - 同一网络内的容器可直接用服务名访问，比如
http://user-svc:8080或curl user-svc:8080/health - 支持 DNS 自动解析，无需额外配置或写死 IP
跨主机部署选 overlay 网络
单机测试用 bridge 就够了；一旦进入生产集群（如 Docker Swarm），必须用 overlay：
- 它在多个 Docker 主机间构建虚拟覆盖网络，容器跨物理机也能像在同一局域网一样通信
- 需初始化 Swarm：
docker swarm init，再创建 overlay 网络：docker network create -d overlay my-overlay - 服务部署使用
docker service create，自动注册到内置 DNS，支持滚动更新和负载均衡 - 注意：overlay 对网络延迟和 MTU 更敏感，建议统一宿主机 MTU 为 1450 并开启 VXLAN
别乱用 host 模式
host 模式虽性能高，但会绕过 Docker 网络栈，带来隐患：
- 容器直接复用宿主机端口，容易端口冲突（比如两个服务都想用 8080）
- 失去网络隔离，一个容器出问题可能影响宿主机或其他容器
- 无法使用内置 DNS，服务发现要自己实现（如配合 Consul 或 etcd）
- 仅适合极少数场景：高性能代理（如 Nginx Ingress）、监控采集器（如 Prometheus node_exporter）
配合编排工具统一管理
手动 docker run 不适合微服务，应交由编排工具自动处理网络：
- Docker Compose：在
docker-compose.yml中定义网络，所有 service 自动接入，服务名即 DNS 名 - Kubernetes：用
Service抽象后端 Pod，通过 ClusterIP 或 Headless Service 实现稳定访问，DNS 格式为service-name.namespace.svc.cluster.local - 无论哪种工具，都应避免在代码里硬编码 IP 或端口，全部走服务名 + 环境变量注入
