Docker的--link机制已弃用，它通过修改/etc/hosts和注入环境变量实现单向通信，但存在IP变更失效等问题；现代推荐使用自定义bridge网络、Docker Compose服务名解析或手动注入变量临时兼容。

Docker 的 --link 机制早已被官方弃用（自 Docker 1.10 起标记为 deprecated，Docker 1.13+ 默认不推荐），它本质上是通过修改容器内的 /etc/hosts 文件和设置环境变量，实现容器间基于名称的单向网络通信。虽然不建议在新项目中使用，但理解其原理有助于排查旧环境问题，也更能凸显现代替代方案的优势。

Link 的工作原理：静态 hosts + 环境变量注入

当你运行 docker run --link redis:db nginx 时，Docker 实际做了两件事：

• 在 nginx 容器的 /etc/hosts 中追加一行：172.17.0.3 db redis（IP 来自 redis 容器当前网络地址），使 nginx 内可通过 db 或 redis 域名访问
• 向 nginx 容器注入一组以 DB_（大写别名）为前缀的环境变量，例如：DB_PORT=tcp://172.17.0.3:6379、DB_PORT_6379_TCP_ADDR=172.17.0.3，供应用读取连接信息

注意：Link 是单向的（nginx 能连 redis，反之不行），且依赖源容器先启动；一旦 redis 容器重启 IP 变更，链接即失效——这是其不可靠的根本原因。

别名替换方案：优先使用用户自定义 bridge 网络

现代 Docker 推荐用自定义 bridge 网络替代 Link，它天然支持容器名 DNS 解析，无需额外配置：

• 创建网络：docker network create mynet
• 启动容器并指定网络与别名：docker run --network mynet --name redis-server redis
docker run --network mynet --name web-app -e REDIS_URL=redis-server:6379 nginx
• 此时 web-app 容器内可直接用 redis-server 作为主机名连接 Redis，Docker 内置 DNS 会自动解析

如需多别名（类似 Link 的 redis:db 效果），可在运行时用 --alias 指定：docker run --network mynet --alias db --name redis-server redis，这样 db 和 redis-server 都能解析到同一容器。

编排场景：用 Docker Compose 统一管理服务别名

对于多容器应用，Docker Compose 是更简洁可靠的方案。服务名默认即为 DNS 名，还可通过 aliases 显式添加别名：

version: '3.8'
services:
  app:
    image: nginx
    depends_on: [redis]
    environment:
      - REDIS_HOST=redis  # 直接用服务名
<p>redis:
image: redis:7
networks:
default:
aliases: ["cache", "db"]  # 其他容器可用 cache 或 db 访问它
</p>

启动后，app 容器内 ping redis、ping cache、ping db 全部可达，且重启、扩缩容时 DNS 自动更新，无 Link 的 IP 失效问题。

兼容旧脚本：手动模拟 Link 的环境变量（不推荐长期使用）

若必须临时适配依赖 DB_PORT 等变量的旧镜像，可在启动时手动注入：

• 先获取目标容器 IP：docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' redis
• 启动时传入变量：docker run -e DB_PORT=tcp://$(REDIS_IP):6379 -e DB_PORT_6379_TCP_ADDR=$(REDIS_IP) nginx

但这只是权宜之计，缺乏自动发现与容错能力，应尽快迁移到基于网络的服务发现模式。