关键在于用 Docker Compose 自定义 bridge 网络实现“分组隔离 + 有控互通”：按前端、后端、数据层划分独立网络，服务仅加入所需网络；中间层（如 api-service）跨网充当通信枢纽；同一网络内通过服务名自动 DNS 解析调用，无需硬编码 IP；务必通过 exec 进容器验证 nslookup、telnet 及 network inspect。
关键在于用好 docker compose 的自定义网络机制，而不是依赖默认桥接网络。默认网络容易引发服务名解析失败、跨服务访问受限或安全边界模糊等问题。真正打通通信，核心是“分组隔离 + 有控互通”。
明确服务角色，划分功能网络
把同类职责的服务归入同一网络，比如前端、后端逻辑、数据库各成一网。这样既避免无关服务互相干扰，又为后续精准打通打下基础。
- 用 bridge 驱动创建独立网络，如
frontend、backend、data - 每个服务只加入它真正需要通信的网络，例如 Nginx 只进
frontend，PostgreSQL 只进data - 禁止所有服务无差别接入默认网络，防止命名冲突和意外连通
让中间层服务充当“桥梁”
不是所有服务都要直连。典型做法是让 API 网关或业务服务同时接入多个网络，成为可控的通信枢纽。
- 比如
api-service同时加入frontend和backend，接收 Web 请求并调用下游 - 再让它加入
data网络，直接连接数据库，但 Web 和 DB 彼此不可见 - 这种结构天然形成三层隔离：接入层 → 逻辑层 → 数据层
靠服务名实现自动发现与调用
Docker 内置 DNS 在同一网络内生效，不需要硬编码 IP 或端口，也不用额外部署注册中心。
- 在
api-service容器里，直接用http://db:5432访问 PostgreSQL - 确保调用方和服务名拼写完全一致（大小写、连字符都敏感）
- 验证方式：进入容器执行
ping db或nslookup db，确认能解析出 IP
调试与验证不能跳过
配置写完不等于通了。必须动手验证实际连通性，尤其关注跨网络路径。
- 用
docker-compose exec <service> sh进入容器 - 测试 DNS 解析：
nslookup db - 测试端口可达：
telnet db 5432或curl -v http://api:8080/health - 查网络拓扑：
docker network inspect <network-name>看容器是否真在其中
