要实现Docker Compose零停机更新，必须同时满足：① replicas≥2；② 配置有效healthcheck（应用监听0.0.0.0）；③ deploy.update_config中order设为start-first、parallelism=1、delay合理；并配合--no-deps精准更新、避免ports宿主机映射、确保Compose CLI≥v2.19且启用实验特性。
要让 Docker Compose 实现真正的平滑重启与更新（即零停机），不能只靠 docker-compose up -d 默认行为——它会先停旧容器、再启新容器，中间必然有服务中断。必须通过显式配置 + 正确操作组合才能达成。
必须配置的三大核心项
缺一不可，否则滚动逻辑不会触发：
- replicas ≥ 2：单副本时即使配置了滚动策略，也无法保证流量不中断；至少两个实例才能实现“新启旧停”的交替
-
healthcheck：定义容器就绪标准，例如：
healthcheck:<br> test: ["CMD", "curl", "-f", "http://localhost:80/health"]<br> interval: 30s<br> timeout: 10s<br> retries: 3
注意：应用必须监听0.0.0.0（而非127.0.0.1），否则健康检查失败 -
deploy.update_config：启用滚动控制，关键子项包括：
–order: start-first（先启新、再停旧，这是零停机的前提）
–parallelism: 1（每次只更新一个副本，降低风险）
–delay: 10s（给新容器冷启动和健康检查留出缓冲时间）
更新时的正确执行方式
避免全量重建引发连锁重启或端口冲突：
- 只更新目标服务：
docker-compose up -d --no-deps web（跳过依赖检查，精准生效） - 生产环境建议加超时保护：
docker-compose up -d --timeout 60 web，防止健康检查卡死导致命令挂起 - 不要用
docker-compose pull && docker-compose up -d组合：pull 失败时 up 仍会执行，可能混用旧镜像+新配置 - 端口映射慎用
ports：宿主机端口（如- "80:80"）无法复用，会导致第二个容器启动失败；应改用expose或依赖内部网络通信 + 反向代理（如 Nginx/Traefik）做流量分发
常见失败原因与快速排查点
更新卡住或反复失败，大概率是底层条件未满足：
-
健康检查一直 fail：检查应用是否监听
0.0.0.0:端口；确认路径/health返回 200 且无认证拦截 - 新容器启动后立刻退出：可能是内存不足（parallelism 设太高）、依赖服务未就绪（此时需应用内实现连接重试，别指望 Compose 等 DB ready）
- 更新后请求 502/超时：反向代理未及时发现新容器（Docker 内置 DNS 轮询有延迟），建议搭配 Traefik 或 Consul 实现自动服务发现
-
配置写了但没生效：确认 Compose CLI 版本 ≥ v2.19（旧版会静默忽略
update_config）；纯 Compose 模式下该功能属实验性，必要时启用COMPOSE_EXPERIMENTAL=1
回滚与稳定性兜底
上线不是终点，失败时快速恢复同样关键：
- 配置
failure_action: rollback，更新失败时自动切回上一版本镜像 - 保留历史镜像标签（如
v1.2.3而非latest），确保回滚可追溯、可验证 - 更新前用
docker-compose config校验 YAML 语法，避免格式错误导致重建异常 - 关键服务建议加
restart_policy: condition: on-failure，应对运行中偶发崩溃
