docker stop 是自动化部署中用于优雅终止旧容器的关键命令，位于部署前准备阶段，通过默认10秒graceful shutdown释放端口等资源，并支持超时调整、信号控制、命名/标签精准操作及健康检查联动。
在自动化部署中，DockerStop本身并不是一个独立命令，而是 docker stop 的常见误写或简写习惯。真正起作用的是 docker stop —— 它负责优雅终止正在运行的容器，是部署流程中关键的“清理”环节。用好它，能避免端口冲突、数据残留、服务启停错乱等问题。
明确 stop 在部署流水线中的定位
docker stop 通常出现在部署前的准备阶段，而非部署后。它的核心作用是：为新版本容器腾出资源（如绑定端口、卷挂载点、网络别名），同时保障旧容器有时间完成正在处理的请求（通过默认 10 秒 graceful shutdown）。
- 典型顺序：stop 旧容器 → 拉取/构建新镜像 → run 新容器 → （可选）健康检查 → 清理旧镜像
- 不建议在 CI/CD 脚本里直接用
docker kill替代，除非确认无状态且可中断 - 若使用 Docker Compose，对应操作是
docker compose down（自动 stop + remove）或docker compose stop（仅停止）
控制超时与信号，避免僵死或强制杀进程
docker stop 默认发送 SIGTERM，等待 10 秒后若容器未退出，再发 SIGKILL。这个行为可调，对不同应用很关键：
- Web 服务（如 Nginx、Spring Boot）：通常几秒内可优雅关闭连接，保持默认 10s 即可
- 批处理或长事务容器：需延长超时，例如
docker stop --time=60 my-app - 自定义终止逻辑：在镜像的
ENTRYPOINT或应用代码中捕获SIGTERM，执行清理（如关闭数据库连接、刷盘缓存）
结合容器命名与标签，精准停止目标实例
自动化脚本中避免用 docker stop $(docker ps -q) 这类模糊操作——容易误停其他环境容器。推荐方式：
- 启动时指定唯一名称：
docker run --name app-prod-v2.1 ...，停止时用docker stop app-prod-v2.1 - 用 label 标记环境与用途：
docker run -l env=prod -l service=api ...，再用docker ps -f "label=env=prod" -f "label=service=api" -q | xargs docker stop - 在 CI/CD 中，把容器名或 label 值作为变量传入，实现多环境隔离
配合健康检查与依赖管理，提升流程鲁棒性
单纯 stop 不代表部署成功。需和前后步骤联动验证：
- stop 前可加轻量检查：
docker ps -f name=app-prod --format "{{.Status}}" | grep -q "Up"，防止重复 stop 报错 - stop 后建议等待几秒再启动新容器，尤其当宿主机资源紧张时
- 若容器依赖数据库等外部服务，stop 本容器前无需停依赖；但整个 stack 升级时，应按依赖拓扑反序 stop（先 app，后 db）
