推荐使用 network aliases 实现服务别名：在 networks 配置中为服务设置 aliases（如 ["cache"]），使依赖容器可通过固定别名访问，服务名变更时仅需更新 aliases，业务代码无需改动。
在 Docker Compose 中，服务名（service name）是容器间通信的默认 DNS 名称，一旦应用代码硬编码了服务名（如 http://redis），而后续因重构、拆分或命名规范调整修改了 docker-compose.yml 中的 service name（比如从 redis 改成 cache-service），就会导致依赖方无法解析、连接失败甚至启动崩溃。
Compose 本身不提供“服务别名”的全局注册机制，但可通过以下三种方式实现**语义稳定、解耦服务名变更**的效果，本质是让调用方始终使用固定标识，而将该标识映射到实际的服务名上。
方式一：用 network aliases 显式绑定别名（推荐）
这是最直接、最符合 Docker 网络设计意图的方式。在 networks 配置中为服务指定 aliases，让所有同网段容器都能通过别名访问该服务，且别名与服务名解耦。
例如，你想让业务服务始终用 cache 这个名字访问 Redis，无论底层服务叫什么：
services:
cache-service:
image: redis:7
networks:
app-net:
aliases: ["cache"] # ← 关键：其他容器可直接用 http://cache:6379
<p>app:
image: myapp:latest
depends_on: [cache-service]
networks: [app-net]
此时 app 容器内执行 ping cache 或连接 redis://cache:6379 均可成功。即使将来把服务重命名为 redis-primary，只需更新 aliases: ["cache"] 所在位置，业务代码完全无需改动。
方式二：通过自定义网络 + 静态 IP + /etc/hosts 模拟（适用于旧版或特殊场景）
当需要更严格的 DNS 控制（比如兼容某些不支持 DNS 别名的客户端库），可配合静态 IP 和 extra_hosts 实现“伪别名”：
- 为关键服务分配固定 IP（在自定义 bridge 网络中）
- 在所有依赖服务中，用
extra_hosts将别名映射到该 IP
networks:
app-net:
driver: bridge
ipam:
config:
- subnet: 172.20.0.0/16
<p>services:
cache-service:
image: redis:7
networks:
app-net:
ipv4_address: 172.20.1.10</p><p>app:
image: myapp:latest
extra_hosts:</p><ul><li>"cache:172.20.1.10" # ← 容器内 /etc/hosts 自动添加
networks: [app-net]
这种方式绕过 DNS，稳定性高，但维护成本略高（需手动管理 IP 分配），适合对启动时连接强一致要求的场景。
方式三：用 environment + 启动脚本动态注入（适合多环境统一配置）
若服务名变更频繁、且希望配置完全外部化，可在启动时通过环境变量传入别名地址，并由入口脚本替换配置文件或生成连接字符串：
- 在
docker-compose.yml中定义统一的环境变量，如CACHE_HOST=cache - 应用镜像的
entrypoint.sh读取该变量，写入配置（如 Spring 的application.yml）或导出为运行时变量 - 代码中统一读取
CACHE_HOST而非硬编码字符串
这样服务名变更只影响 compose 文件中的变量值，不触及镜像和代码逻辑，也便于不同环境（dev/staging/prod）使用不同别名策略。
不复杂但容易忽略：别名必须定义在 同一网络 下才生效；跨网络访问需额外配置 external_links（已弃用）或共享网络；生产环境建议配合健康检查与依赖等待（depends_on + condition: service_healthy）进一步防崩。
