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

核心区别：links 建立的是网络连通性**（容器间可访问+别名解析），是 Compose 早期的互联机制，现已废弃——因为同一 compose 项目的服务默认就在同一网络、天然互通；depends_on 控制的是启动顺序（可配条件等就绪），两者语义完全不同，现代写法只需要 depends_on。**

links：历史遗物

services:
  web:
    links:
      - db        # 旧式写法：连通 + 创建别名
  db:
    image: postgres

当年它的作用：让 web 能访问 db 并解析 db 这个名字。而今天的 compose：所有服务自动接入项目网络，服务名就是 DNS 名——不写任何东西，web 里直接 psql -h db 就通。links 已没有存在价值。

depends_on：启动顺序控制

services:
  web:
    depends_on:
      - db
  db:
    image: postgres

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

services:
  web:
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10

对比速查

迁移老配置

见到 links 的老 yml：直接删掉 links 段，检查是否同时需要 depends_on（为了顺序），通信本身不用任何配置。

观测云对照

启动时序故障最易观察。 应用先于数据库启动导致的连接拒绝风暴，在观测云日志里呈现为启动段密集报错；配上 depends_on + healthcheck 后这类噪声消失，对照前后日志量曲线即知。

常见问题（FAQ）

Q：不写 depends_on 服务也能互相访问？
A：能。同一 compose 网络内任何时刻都能按服务名互访；depends_on 只管谁先谁后启动。

Q：depends_on 等待会超时失败吗？
A：condition: service_healthy 模式下 compose up 会等待健康检查通过；一直不健康则 up 卡住/失败，符合预期（宁可别起）。

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