docker-compose.yml 中 links 和 depends_on 有什么区别？

核心区别：links 提供旧式链接别名并隐含启动依赖，不会绕过网络成员限制，是 Compose 早期的互联机制，现代配置通常无需使用，但Compose规范仍描述该字段，支持依实现而异——因为同一 compose 项目的服务默认就在同一网络、天然互通；depends_on 控制的是启动顺序**（可配条件等就绪），两者语义完全不同，现代配置通常使用共同网络，并按需要配置 depends_on。**

links：历史遗物

services:
  web:
    links:
      - db        # 旧式链接别名及隐含启动依赖
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?请先安全设置初始化密码}

当年它的作用：让 web 能访问 db 并解析 db 这个名字。而今天的 compose：未显式配置网络的服务默认接入项目网络，服务名就是 DNS 名——web 可用 db 解析地址，连接还需数据库已就绪、监听和认证配置允许。既有links可能还承担别名和依赖作用，迁移需保留这些语义。

depends_on：启动顺序控制

services:
  web:
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?请先安全设置初始化密码}

保证 db 先于 web 启动。注意默认只等"容器起来了"，不等"服务就绪"；要等数据库真能接连接：

services:
  web:
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?请先安全设置初始化密码}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U postgres"]
      interval: 5s
      retries: 10

对比速查

迁移老配置

见到 links 的老 yml：检查共同网络、链接别名与隐含依赖，按需用network aliases和depends_on替代，再移除links。

迁移后重启一次服务，检查应用首次连接数据库的结果。如果日志已通过 DataKit接入观测云，可按本次启动时间检索连接拒绝和重试记录，再核对数据库就绪的时间；日志减少只能说明这次启动有所改善，运行中的断连仍需应用自己的重试机制处理。

常见问题（FAQ）

Q：不写 depends_on 服务也能互相访问？
A：能。同一 compose 网络内可按服务名解析，但实际通信仍需目标监听、网络策略及就绪状态允许；depends_on 只管谁先谁后启动。

Q：depends_on 等待会超时失败吗？
A：condition: service_healthy 模式下 compose up 会等待依赖健康检查通过；依赖变为 unhealthy 会使启动失败。它不是持续依赖监控，应用仍需重试和重连；pg_isready 也不代表应用凭据或数据库迁移已就绪。

Q：K8s 里对应什么？
A：initContainers（等依赖就绪再启动主容器）+ 应用自重试，没有 depends_on 的直接等价物。