必须使用自定义桥接网络实现业务容器隔离，因其支持容器名解析、网络范围可控、可配置子网等参数，而默认bridge网络缺乏隔离能力；例如创建user-service-net网络并指定子网，使user-api与user-db可互通，但无法访问order-service-net中的容器。
要让不同业务的容器真正互不干扰，核心就是用自定义桥接网络划出清晰边界。默认的 bridge 网络是“大杂烩”——所有没指定网络的容器都挤在里面，能互相 ping 通、通过 IP 访问，甚至可能因端口冲突或服务暴露带来风险。自定义桥接网络则像给每个业务建个独立办公室，门一关，彼此看不见。
为什么必须用自定义 bridge 而不是默认 bridge？
默认 bridge 网络不支持容器名解析（只能靠 IP 通信），无法动态增删容器网络连接，且所有容器共享同一子网和 DNS 行为，隔离形同虚设。而自定义 bridge 网络天然具备：
- 容器间可通过服务名直接通信（如
curl http://api:8080） - 网络范围可控，跨网络的容器默认不通（无需额外防火墙规则）
- 可单独配置子网、网关、MTU、IPAM 等参数
- 容器运行中可随时
docker network connect/disconnect
创建一个带子网的业务隔离网络
比如为用户服务建一个专属网络：
docker network create \ --driver bridge \ --subnet 172.20.10.0/24 \ --gateway 172.20.10.1 \ user-service-net
这个命令做了三件事：指定使用桥接驱动、划分独立 IP 段（避免和其它网络重叠）、设定网关地址。后续连入该网络的容器，IP 都会从 172.20.10.2–172.20.10.254 中自动分配。
把容器放进对应网络
启动时显式指定网络名，而不是依赖默认：
docker run -d --name user-api --network user-service-net nginx:alpine docker run -d --name user-db --network user-service-net postgres:15
这两个容器现在处于同一网络内，user-api 可直接用 http://user-db:5432 连接数据库；而订单服务如果连的是 order-service-net，它就完全 ping 不通 user-db，也看不到它的端口。
多业务网络并存时的注意事项
- 网络名必须全局唯一（如
user-service-net、order-service-net、payment-service-net） - 子网 CIDR 不能重叠（例如
172.20.10.0/24和172.20.20.0/24是安全的，但两个都用172.20.0.0/16就会冲突） - 不需要互通的业务网络之间，Docker 默认不路由，这点比手动 iptables 更可靠
- 若某业务需对外提供服务，仍需
-p 8080:80映射端口，网络隔离不影响宿主机端口暴露
验证隔离是否生效
在 user-api 容器里执行：
ping order-db # 会超时（不同网络，DNS 解析失败 + 网络层不通） ping user-db # 成功（同网络，名称可解析，路由可达）
只要没主动 docker network connect，跨网容器就像不在同一个世界。
