docker compose 中 aliases 实现服务发现需使用自定义网络，各服务须在 networks 下嵌套配置 aliases，仅同网络容器可解析别名，优先匹配别名再服务名，最后外网 dns。
在 Docker Compose 中配置 aliases 实现服务发现，核心是让同一自定义网络内的容器能用语义化名称（如 frontend、database）互相访问，而不是硬写服务名或 IP。这依赖 Docker 内置 DNS 的自动解析，但必须满足几个关键前提。
必须使用自定义网络
Docker 默认的 bridge 网络不支持别名解析，所有 aliases 配置只在用户定义的桥接网络（或覆盖网络）中生效。
- 在
networks顶层声明一个自定义网络，例如app-network - 每个服务必须显式加入该网络（不能只写
networks: - app-network，而要带aliases子项） - 避免混用默认网络和自定义网络——别名不会跨网络传播
正确写法：在 service → networks → network-name 下设 aliases
别名不是服务级配置，而是“服务在某网络中的别名”，所以结构必须嵌套准确：
services:
web:
image: nginx
networks:
app-network: # ← 必须指定网络名（不是列表）
aliases:
- frontend
- dashboard.local
<p>api:
image: myapi
networks:
app-network:
aliases:</p>
- backend
- service-api
networks: app-network: driver: bridge
错误写法示例：networks: - app-network 后直接跟 aliases，这样别名不会被识别。
别名生效范围与解析逻辑
别名仅对「同属该自定义网络」的其他容器有效，且解析优先级固定：
- 容器发起请求时（如
curl http://frontend），Docker DNS 先查是否为当前网络中任一服务的别名 - 若匹配，返回对应容器的虚拟 IP（如
172.20.0.3） - 若不匹配，再查是否为同一网络中的服务名（如
web） - 最后才转发给外部 DNS（如你主机的
8.8.8.8）
这意味着：app 容器能解析 frontend，但宿主机或另一个网络里的容器无法解析它。
验证别名是否生效
启动后进入任一容器，用 nslookup 或 ping 测试：
docker-compose exec api sh # 在容器内执行： nslookup frontend # 应返回 web 容器的 IP nslookup database # 若 db 也加入了同一网络并设了该别名，也应成功 ping -c 2 backend # 应通（注意：ping 不依赖端口，只测连通性）
如果失败，常见原因有：网络未共享、别名拼写不一致、服务未真正运行在该网络中（可用 docker network inspect app-network 查看容器列表和别名注册情况）。
