docker compose 通过自定义 bridge 网络实现内网安全隔离：为 frontend、backend、data 分别创建独立网络，服务仅加入所需网络，禁用 ports 和 host 模式，确保跨网容器无法解析、ping 通或访问。
用 docker compose 实现多服务编排下的内网安全隔离与访问控制，核心是“网络即策略”——不靠暴露端口、不靠应用层鉴权，而是通过 docker 原生网络拓扑强制约束通信路径。只要网络不连通，容器之间就天然无法访问，这是最轻量也最可靠的隔离基础。
定义独立自定义网络
避免使用默认 bridge 网络（所有服务默认互通），显式声明多个隔离网络：
- 每个网络对应一个逻辑区域，比如 frontend（面向用户）、backend（业务逻辑）、data（数据库/缓存）
- 使用 bridge 驱动即可满足单机部署需求，无需 overlay（跨主机才需）
- 网络名就是 DNS 域名空间，服务可通过服务名直接解析，无需 IP 或端口映射
按角色分配网络接入权限
服务只能访问它明确加入的网络，其他网络中的容器对其完全不可见：
- web 服务只连 frontend 网络 → 只能调用同网的 api（若 api 也在 frontend）
- api 同时连 frontend 和 backend → 充当通信桥梁，可收前端请求、发后端请求
- db 只连 backend 网络 → 外部无法 ping 通、telnet 不通、DNS 解析失败
禁止隐式互通与端口暴露
进一步收紧边界，消除绕过网络隔离的可能：
- 所有服务禁用 ports 字段（除非必须对外暴露，如 web 的 80/443）
- 数据库类服务绝对不写
ports: ["5432:5432"]，否则即使不在同一网络，宿主机也能直连 - 不使用
network_mode: "host"，它会绕过所有 Docker 网络隔离 - 敏感服务（如 Redis、Elasticsearch）不配置 expose，该字段仅用于文档说明，无实际隔离作用
验证隔离效果是否生效
部署后立即执行简单连通性测试，确认策略落地：
- 进入 web 容器：
docker exec -it <web-container> sh</web-container> - 尝试解析 db 服务：
nslookup db→ 应返回“server can't find db” - 尝试 ping db：
ping db→ 应超时或报“unknown host” - 进入 api 容器重复上述步骤 → 应能成功解析并连通 db
