关键在于用自定义bridge网络为生产与测试环境分别创建独立netns，如prod-net和test-net，二者默认路由隔离、互不可达；须禁用host/container模式、关闭默认bridge互通，并通过cni或iptables补强东西向策略，最后实测验证netns分离与跨网不通。
要让生产环境和测试环境在同一个 Docker 主机上安全共存，关键不是“物理隔离”，而是利用网络命名空间（netns）构建逻辑上互不可见、策略可控的通信边界。Docker 本身不提供“多环境自动隔离”，但它的网络模型天然支持这种分层控制——核心在于选对网络驱动、配好网络模式，并辅以显式策略约束。
用自定义 bridge 网络划分环境域
默认的 bridge 网络（docker0）所有容器默认可互通，不适合混跑生产与测试。必须创建独立的自定义 bridge 网络，为每个环境分配专属 netns：
- 为生产环境建网：
docker network create --driver bridge --subnet=192.168.100.0/24 prod-net - 为测试环境建网：
docker network create --driver bridge --subnet=192.168.200.0/24 test-net - 启动容器时显式指定网络：
docker run --network prod-net --name api-prod ...和docker run --network test-net --name api-test ... - 两个网络之间默认无路由，
ping、curl均不通——这是 netns 隔离的直接体现，无需额外防火墙规则
禁用跨网通信，堵住隐式连通路径
即使用了不同 bridge 网络，仍需防范三类常见“破防”场景：
-
避免使用 host 模式：任何容器若启用
--network=host，就完全退出 netns 隔离，能直接访问宿主机所有端口，也暴露自身服务——生产与测试容器都应禁止该模式 -
慎用 container 模式共享 netns：如
--network=container:api-prod会让新容器和生产 API 共享 IP 与端口空间，极易引发端口冲突或越权访问 -
关闭默认 bridge 的容器互通：可通过
dockerd启动参数--default-network=none或在 daemon.json 中设"default-address-pools": []，强制所有容器必须显式指定网络
用 network policy 或 iptables 补强东西向控制
自定义 bridge 提供基础隔离，但无法精细控制“谁可以访问谁”。若需更细粒度策略（例如：测试数据库只允许测试应用访问，禁止生产应用探测）：
- 推荐使用 CNI 插件（如 Calico 或 Cilium），它们在每个容器 netns 内注入 eBPF 或 iptables 规则，实现 Pod/容器级策略
- 若用原生 Docker，可在宿主机上针对 docker0 或自定义网桥的 veth 接口加 iptables 规则，例如：
iptables -I FORWARD -i vethabc123 -o vethdef456 -j DROP（需根据实际 veth 名动态匹配） - 也可在容器启动时注入轻量级防火墙工具（如 nftables），在 netns 内部设白名单端口
验证隔离是否真正生效
不能只靠“没配置就不通”，必须实测验证 netns 边界：
- 查两个容器是否处于不同 netns：
docker inspect -f '{{.State.Pid}}' api-prod→ 得到 PID A；再查 PID B；然后执行ls -l /proc/A/ns/net与ls -l /proc/B/ns/net，确认 inode 编号不同 - 从 prod 容器内尝试访问 test 容器 IP：
docker exec api-prod ping 192.168.200.2，应超时 - 检查路由表：
docker exec api-prod ip route，输出中不应出现 test-net 的子网路由 - 抓包验证：
docker exec api-prod tcpdump -i eth0 port 6379，在 test 容器发 Redis 请求，应无捕获数据包
