子网变动导致微服务失联的本质是服务发现失效与网络连通性中断叠加；应通过自定义网络替代默认bridge、固定子网、服务名通信、全局bip配置及应用层重试熔断，实现拓扑与寻址解耦。
子网变动导致微服务失联，本质是服务发现失效和网络连通性中断的叠加问题。关键不在于“避免变动”，而在于让服务通信不依赖具体子网地址——通过解耦网络拓扑与服务寻址来实现弹性。
用自定义网络替代默认桥接
默认 bridge 网络由 Docker 自动分配子网（如 172.17.0.0/16），一旦宿主机或企业内网也用了该段，就会路由冲突。微服务启动后可能获取到不可达 IP，或 DNS 解析失败。
- 在
docker-compose.yml中显式定义网络，并固定子网，例如：networks:<br> app-net:<br> driver: bridge<br> ipam:<br> config:<br> - subnet: 172.25.0.0/24
- 所有服务统一接入该网络，不再依赖默认网络；服务名解析由 Docker 内置 DNS 自动完成，与子网地址无关
- 多个项目使用不同子网（如
172.25.0.0/24、172.26.0.0/24），从根源上规避交叉干扰
服务通信不硬编码 IP 或子网
微服务之间应始终通过服务名（而非 IP）调用，且配置中避免写死任何与子网相关的参数（如网关、DNS 服务器地址）。
- 确保每个服务只声明所需网络，例如前端只连
frontend网络，数据库只连backend网络，减少跨网暴露面 - 环境变量或配置中心里不要填
http://172.25.0.10:8080这类地址，改用http://api:8080 - 若需外部访问，用
ports映射宿主机端口，而不是依赖容器 IP 直连
提前规避子网冲突风险
子网变动常源于新部署抢占了已有网段，或 Docker 守护进程重启后重选子网。主动管理才能防患于未然。
- 修改
/etc/docker/daemon.json，全局指定基础网段：{ "bip": "172.25.0.1/24", "default-address-pools": [{ "base": "172.26.0.0/16", "size": 24 }] } - 开发、测试、生产环境使用不同 CIDR 段（如
172.25.0.0/24、172.26.0.0/24、172.27.0.0/24），避免配置混用 - 上线前执行
arping -I docker0 172.25.0.1类似探测，确认目标子网未被物理设备占用
增强故障恢复能力
即使子网临时变动，也要保证服务能快速重建连接，而不是卡在初始化阶段。
- 应用层加入重试与熔断逻辑，对首次 DNS 解析失败或连接超时做退避重试
- 健康检查路径（
healthcheck）应走服务名调用，验证的是服务可达性，不是网络配置正确性 - 配合
restart: unless-stopped和合理的启动顺序（depends_on+ 自定义健康检查），让容器在子网就绪后再启动
