docker stop 是让容器优雅停止的标准方式，它先发 SIGTERM 给 PID 1 进程并默认等待 10 秒，超时未退出则发不可捕获的 SIGKILL；应用需直接运行可执行文件、注册 SIGTERM 处理器且清理耗时不超过宽限期，可通过 --time 或 stop_grace_period 调整等待时间，验证需检查日志及关键动作是否完成。
执行 docker stop 是让容器优雅停止的标准方式，核心在于它不直接“杀”进程，而是通过信号机制给应用留出清理时间。
stop 命令的两阶段终止流程
Docker stop 不是一次性终结，而是一个有节奏的退出过程：
- 第一阶段：向容器内 PID 1 进程发送 SIGTERM 信号，通知“准备关闭”，默认等待 10 秒
- 第二阶段：若超时后进程仍未退出，自动发送 SIGKILL 强制终止（该信号不可捕获、无法延迟）
服务能真正“优雅”的前提条件
仅靠 docker stop 命令本身不够，应用必须配合才能完成优雅关闭：
- 主进程需直接运行可执行文件（如
CMD ["./app"]），避免 shell 封装导致信号丢失 - 代码中要注册 SIGTERM 信号处理器，触发关闭逻辑（如关闭 HTTP server、断开数据库连接、保存未写入数据）
- 确保清理操作耗时不超过 stop 的等待时间，否则会被 SIGKILL 中断
控制宽限期的实用方法
10 秒是默认值，但多数业务场景需要更长缓冲。可通过以下方式调整：
- 命令行指定：
docker stop --time=30 my-app - 启动时设置：
docker run -d --stop-timeout=30 myapp - Docker Compose 中配置：
stop_grace_period: 30s
验证是否真正支持优雅关闭
别只看容器停了没，要确认清理逻辑是否执行成功：
- 手动测试：
docker kill --signal=SIGTERM <container>，观察日志中是否有“收到 SIGTERM”“正在关闭”等输出 - 检查退出前是否完成关键动作：连接是否释放、临时文件是否清理、HTTP 请求是否处理完毕
- 避免用
docker kill替代docker stop，前者默认发 SIGKILL，跳过所有优雅环节
