使用服务名或网络别名替代IP可解决硬编码问题；Docker Compose在自定义桥接网络中自动解析别名，需显式定义network并让服务加入；别名可多设、仅限本网络生效；代码中统一用别名访问；配合healthcheck与重试保障可用性。
直接用服务名或网络别名替代IP地址，就能彻底避开硬编码IP的问题。Docker Compose 内置的 DNS 机制会在同一自定义网络中自动把别名解析成当前容器的实际 IP，容器重启、扩缩容都不影响通信。
必须使用自定义桥接网络
默认的 bridge 网络不支持服务发现和别名解析，所有别名功能都依赖用户定义的网络。配置时要显式声明 network，并指定 driver: bridge：
- 在 networks 顶层定义一个网络，比如 app-network
- 每个服务都要通过 networks 字段加入该网络，不能只写服务名
- 避免混用默认网络和自定义网络，否则别名在部分容器里不可见
为服务配置多个语义化别名
别名不是替代服务名，而是补充——一个服务可拥有多个别名，按环境、角色或协议区分，提升可读性与适配性：
- 数据库服务可同时设别名 db（通用）、mysql-backend（明确类型）、storage（业务含义）
- 网关服务可用 api-gateway 和 ingress，方便不同模块按习惯调用
- 别名只在所属网络内生效，跨网络访问需额外路由或共享网络
应用代码里统一使用别名连接
所有服务间调用地址应写成 http://backend、mysql://database:3306 这类形式，而非 172.x.x.x 或 localhost:
- Spring Boot 的 spring.datasource.url 改为 jdbc:mysql://database:3306/mydb
- Node.js 中的 axios 请求目标设为 http://auth-service/login
- 避免在代码或配置文件中拼接 IP + 端口，也别用 host.docker.internal 替代——它不跨容器、不跨平台、不稳定
配合健康检查保障解析可用性
别名能解析不代表服务已就绪。容器启动快，但数据库监听端口可能延迟就绪，导致早期请求失败：
- 为被依赖服务添加 healthcheck，例如检测 mysql 3306 端口是否可连通
- 调用方通过 depends_on + condition: service_healthy 控制启动顺序
- 应用自身也建议实现重试逻辑，别完全依赖启动时序
