Docker Compose重启无顺序控制，需应用层实现依赖等待：1. depends_on+service_healthy在up时生效；2. entrypoint嵌入wait-for-it.sh对所有重启有效；3. 应用内建重试机制最健壮。
Docker Compose 本身不控制“重启顺序”，只控制初始启动顺序。当你执行 docker compose restart 或服务因崩溃自动重启时，各服务是并行重启的，不会按 depends_on 或健康状态再次排队。真正能影响重启行为的，是服务之间的依赖感知逻辑是否在应用层实现。
要让容器在重启后仍按需等待依赖就绪，关键不是改 Compose 的“重启顺序”，而是确保每次启动（包括重启）都执行等待逻辑。以下是三种切实可行的方法：
用 depends_on 配合健康检查控制重启时的依赖感知
depends_on 单独使用只等容器运行，不等服务就绪；但加上 condition: service_healthy 后，Compose 会在每次启动（含重启）前检查目标服务是否处于 healthy 状态。
version: "3.8"
services:
db:
image: postgres:13
environment:
POSTGRES_DB: myapp
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d myapp"]
interval: 10s
timeout: 5s
retries: 5
start_period: 40s
web:
build: .
depends_on:
db:
condition: service_healthy⚠️ 注意：restart 命令本身不触发 depends_on 重校验，但如果你用 docker compose up -d --force-recreate web 或先 down 再 up，就会重新走依赖流程。真正可靠的场景是服务崩溃后由 restart: unless-stopped 触发的重启——此时 Web 容器会重新启动，并在启动命令中主动等待 DB 健康。
在服务启动命令中嵌入等待脚本（适用于所有重启）
把等待逻辑写进容器的入口点，这样无论容器是首次启动、手动重启还是崩溃自启，都会执行等待。
以 wait-for-it.sh 为例：
- 下载脚本到项目目录：
curl -o wait-for-it.sh https://raw.githubusercontent.com/vishnubob/wait-for-it/master/wait-for-it.sh - 修改权限：
chmod +x wait-for-it.sh - 在
docker-compose.yml中挂载并覆盖启动命令：
web:
build: .
volumes:
- ./wait-for-it.sh:/wait-for-it.sh
entrypoint: ["/wait-for-it.sh", "db:5432", "--timeout=60", "--"]
command: ["npm", "start"]✅ 这种方式对 docker compose restart web 也生效，因为重启会重新执行 entrypoint + command。
使用自定义健康检查 + 应用级重试机制（最健壮）
不依赖外部脚本，由应用自身处理依赖失败。例如 Node.js 项目中：
- 启动时尝试连接数据库，失败则休眠后重试（最多 10 次）
- 连接成功后再启动 HTTP 服务
这样即使 DB 临时不可用，Web 容器也不会退出，而是持续等待，自然适配任意重启场景。
常见做法示例（伪代码）：
async function startApp() {
for (let i = 0; i < 10; i++) {
try {
await db.connect(); // 如 pg.connect()
console.log("DB ready");
app.listen(3000);
return;
} catch (e) {
console.log(`Attempt ${i + 1} failed, retrying...`);
await sleep(3000);
}
}
process.exit(1);
}这种方式解耦强、无额外依赖，适合生产环境。
不复杂但容易忽略
