docker stop 是干什么的
docker stop 优雅停止容器：先给容器主进程发送可捕获的终止信号，等应用保存状态、处理完存量请求，超时后再发强制终止信号。默认等待时间有限，对需要较长收尾时间的应用要显式调大等待时间，否则会被强制杀掉并丢失正在处理的请求。
基本信息
| 信号流程 | 先发可捕获的终止信号，超时后再强制终止 |
|---|---|
| 等待时间 | 用超时参数控制，默认值较短，长收尾流程需要调大 |
| 与强杀对比 | 直接强杀不给应用任何收尾机会，容易丢数据 |
| 批量停止 | 可对多个容器一次性执行，生产环境务必先确认范围 |
| 返回值 | 命令返回即表示停止完成，但要确认退出方式是否符合预期 |
| 重启策略 | 设置了自动重启的容器会在停止后按策略重新拉起 |
典型使用场景
- 发布前的有序下线：让应用先停止接收新请求再退出
- 维护窗口操作：停机做数据迁移或配置变更
- 释放资源：临时容器用完及时停止，避免长期占用内存
- 故障隔离：异常容器先停下来避免继续影响下游
- 验证优雅退出：确认应用能正确处理终止信号，为编排环境做准备
- 批量重启：配合批量命令对一组容器做滚动式停止与启动
停止方式对比
| 方式 | 行为 | 适用场景 |
|---|---|---|
| 带超时的优雅停止 | 先通知再等待，超时后强杀 | 默认选择，兼顾安全与效率 |
| 调大超时 | 延长等待时间 | 收尾流程长、正在处理长请求 |
| 直接强杀 | 立即结束进程 | 进程已无响应、必须立刻释放资源 |
| 批量停止 | 对多个容器依次执行 | 整批下线，需先确认范围 |
停止示例
停止示例
docker stop myapp # 默认等待时间
docker stop -t 30 myapp # 等待 30 秒
docker ps -a --filter "name=myapp" # 确认停止结果
docker logs --tail 50 myapp # 核对退出前是否完成收尾
# 收到终止信号就立刻退出的应用，需要先修优雅退出逻辑应用收到终止信号后应先停止接收新请求、处理完存量请求再退出；没做优雅退出的服务会丢请求，只是往往在低峰期不容易被发现。
等待时间不是越长越好：设得过长会让发布与重启流程长时间卡住，建议按最长请求处理时间来设定。
编排环境下的停止流程由平台发起，参数与容器运行时配置一致：本地验证通过后再上编排，能避免发布时才发现收尾逻辑有问题。
批量停止影响面很大：先确认筛选范围只包含目标容器，生产环境建议逐个环境、逐批执行。