docker stop 不直接执行回滚，而是通过可控终止新版本容器、配合超时控制（如-t 45s）、应用优雅退出处理及stop后状态验证，确保旧版本能安全恢复。
在自动化流水线中，docker stop 本身不直接执行回滚，但它承担着“安全断后”的关键角色——确保旧版本实例在新版本上线前被**可控、可观察、不残留**地终止。真正实现安全回滚，是 stop 行为与前置部署策略、信号处理、超时控制三者协同的结果。
明确 stop 在回滚流程中的定位
回滚不是简单重启旧镜像，而是“下掉新版本 → 恢复旧版本 → 验证旧版本就绪”。其中，docker stop 负责第一环节的收尾：它必须可靠终止新版本容器，避免端口占用、连接泄漏或状态冲突，否则旧版本可能因资源争抢而启动失败或行为异常。
设置合理且一致的 stop timeout
回滚过程讲求确定性，不能因某次 stop 卡住而无限等待。需统一配置足够但不过长的超时值：
- Docker CLI：使用
docker stop -t 45 <new-container> - Docker Compose：在
docker-compose.rollback.yml中为新服务设stop_grace_period: 45s - Kubernetes 回滚场景：确保
terminationGracePeriodSeconds: 45≥ 应用清理逻辑预期耗时
45 秒是经验阈值：覆盖多数数据库连接池关闭、消息确认、日志刷盘等操作；超过该值应视为异常，触发告警而非静默等待。
确保应用能响应 stop 并快速退出
若新版本容器主进程忽略 SIGTERM 或清理卡死，docker stop 最终只能强杀（SIGKILL），导致连接未释放、事务未提交、文件未落盘——这会污染回滚环境。必须做到：
- 确认 PID 1 是应用进程（非 shell 包装器），可用
docker exec <new-container> ps -p 1验证 - 应用代码显式监听
SIGTERM：Java 用@PreDestroy，Go 调srv.Shutdown()，Node.js 监听process.on('SIGTERM') - 所有清理步骤加硬性超时兜底，例如 Go 中用
context.WithTimeout(ctx, 30*time.Second)包裹 shutdown 流程
流水线中嵌入 stop 后验证动作
停掉新容器只是开始，必须确认它已真正退出且无残留影响：
- 检查
docker ps -a输出，确认容器状态为Exited，且退出码非异常值（如 137 表示被 SIGKILL 杀死，需排查） - 搜索容器日志中 “shutting down”, “graceful exit”, “all connections closed” 等关键词，确认优雅退出完成
- 在启动旧版本前，执行端口探测或轻量健康检查，确保原绑定端口已释放、数据库连接池已清空
这些验证点应写入 CI 脚本，任一失败即中断回滚流程，避免带病切换。
