docker stop 是什么
docker stop 优雅停止运行中的容器：先给主进程发送终止信号，等待进程自行收尾，超过等待时间仍不退出才强杀。这个顺序的意义在于让应用有机会关闭连接、写完缓冲区、提交事务，而不是被一刀切断。
基本信息
| 语法 | docker stop [-t 秒] CONTAINER... |
|---|---|
| 信号流程 | 先发终止信号，等待超时后发强杀信号 |
| 默认等待 | 十秒，可用参数为本次操作单独调整 |
| 状态变化 | 从运行中变为已停止，容器对象与可写层完整保留 |
| 恢复方式 | 启动命令可让它回到运行状态，配置不会被改动 |
典型使用场景
- 版本更新的停旧起新：先停干净再启动新版本，减少端口与数据文件的冲突
- 计划内维护：夜间停掉一批服务做数据整理，完事后再启动
- 释放资源：临时起的测试容器用完及时停止，避免长期占用内存
- 数据服务重启：数据库、消息队列需要给足收敛时间，避免出现恢复过程
- 批量处置：按标签或名称筛出目标集合后统一停止，例如停掉开发环境的一批服务
常用示例
常用示例
docker stop web # 默认等待十秒
docker stop -t 30 db # 有状态服务给足收敛时间
docker stop $(docker ps -q --filter label=env=dev) # 按标签批量停止
docker ps -a --filter status=exited # 确认已经停下来
docker start web # 需要时原地恢复运行与强杀方式的对照
| 对比项 | 优雅停止 | 直接强杀 |
|---|---|---|
| 信号 | 先终止信号，后强杀信号 | 立即强杀信号 |
| 等待 | 默认十秒，可用参数调整 | 不等待 |
| 数据安全 | 应用有机会落盘与提交 | 正在写的数据可能损坏 |
| 适用场景 | 数据库、消息队列、有状态服务 | 进程已无响应、必须立刻中断的场景 |
| 退出码表现 | 正常收尾时为常规退出码 | 多为被强杀的退出码 |
停之前要确认的事
- 确认目标集合正确，命令替换写在脚本里尤其要先打印出来核对一遍
- 有状态服务先确认没有正在执行的批处理任务，避免中断造成数据不一致
- 多实例服务确认摘流已完成，避免仍有请求打到即将停止的实例
- 集群环境优先用编排层提供的停止方式，让它按顺序与健康状态处理
- 停完看日志确认是正常收尾，出现异常堆栈说明等待时间可能不够
停止只影响进程，容器对象与可写层都保留，随时可以再启动。真正会丢数据的是删除容器或删除卷，别把这两件事混为一谈。
容器内进程数多时，信号只会发给主进程。应用自己负责转发信号时子进程才能一起退出，否则主进程退出后残留进程可能变成孤儿。
批量停止的执行顺序
- 先摘流量再停进程，让上游把请求收敛后再停止实例，能显著减少失败请求
- 有依赖关系的服务按方向停止，被依赖的先留一会儿，避免依赖方反复重试
- 多实例分批停止，一批停完确认可用性再停下一批
- 停完核对状态列表，确认没有卡在停止中的实例，必要时查看日志找原因
- 记录停顿时间，为下次维护窗口估算时长，数据库类服务尤其需要依据
把默认等待时间调大只解决这一次操作；要让应用每次都优雅退出，正确做法是让应用正确处理终止信号，并在部署配置里统一设置等待时间。