Bridge网络本身不支持别名解析，仅自定义bridge网络具备内置DNS和别名功能；默认bridge网络（docker0）无法通过别名通信，必须使用显式创建的自定义网络，其内嵌DNS才自动解析服务名与别名。
Bridge 网络本身不支持容器别名解析，只有自定义 bridge 网络才具备内置 DNS 和别名功能。默认的 bridge 网络（即 docker0）无法通过别名通信，这是 90% 开发者踩坑的根源。
必须用自定义 bridge 网络
别名（--network-alias）只在用户显式创建的 bridge 网络中生效。Docker 的嵌入式 DNS 服务仅在此类网络中运行，自动将别名映射到容器 IP。
- 创建自定义网络：
docker network create app-net - 启动容器并指定别名：
docker run -d --name db --network app-net --network-alias database postgres - 其他容器连入同一网络后，可直接用
http://database:5432访问
别名与服务名不是一回事
在自定义 bridge 网络中，容器名（如 db）和别名（如 database）都可被 DNS 解析，但作用不同：
- 容器名由
--name指定，全局唯一，且只能在一个网络中解析 - 别名由
--network-alias设置，可重复、可多值，且只在当前网络生效 - 多个容器可共用同一个别名（如两个
cache实例），DNS 轮询返回任一 IP，天然支持简单负载均衡
Docker Compose 中的别名写法
在 docker-compose.yml 里，别名通过 networks.<network-name>.aliases 字段声明：
services:
api:
image: my-api
networks:
app-net:
aliases:
- backend
- service-api
<p>networks:
app-net:
driver: bridge
这样，同一网络中的其他服务就能用 backend 或 service-api 访问该 API 容器，无需硬编码 IP 或容器名。
别名解析范围严格受限
别名只在所属网络内有效，跨网络不可见。例如：
- 容器 A 在
app-net中注册别名redis，容器 B 连入app-net→ 可解析redis - 容器 C 连入
default或另一个自定义网络cache-net→ 解析失败，返回 NXDOMAIN - 这种隔离性不是缺陷，而是设计：避免命名冲突，保障环境边界清晰
