Docker容器停止需区分优雅关闭与强制终止：docker stop先发SIGTERM信号，给予默认10秒宽限期让应用清理资源；超时未退出则发不可捕获的SIGKILL强制终止。
停止 Docker 容器不是简单“关掉”就行，关键在于区分场景：需要数据安全和状态完整时，必须走优雅关闭；容器卡死无响应时，才考虑强制终止。核心差异在于信号类型和应用是否能响应。
优雅关闭：让容器自己收好尾巴
执行 docker stop 是标准做法。它先向容器主进程（PID 1）发送 SIGTERM 信号，给应用留出清理时间，默认等待 10 秒。
- 应用需主动监听 SIGTERM，比如关闭 HTTP 服务、提交事务、断开数据库连接、刷盘日志等
- 若应用在时限内退出，容器状态显示 Exited (0)，说明流程正常
- 可通过 docker logs <container> 查看末尾是否有 shutting down、gracefully stopping 等日志，确认是否真正响应
- 对慢速服务（如 PostgreSQL、Elasticsearch），建议显式加超时，例如：docker stop --time=30 my-db
批量优雅停止所有运行中容器
适合部署更新或日常维护，避免逐个操作：
- docker stop $(docker ps -q) —— Linux/macOS/PowerShell 下最常用
- 想排除关键容器（如数据库），可结合过滤：docker stop $(docker ps -q --filter "label!=role=db")
- 若用 Compose 管理，直接 docker-compose stop，它会按依赖顺序停止，并尊重
stop_grace_period设置
强制终止：只在必要时使用
当容器不响应 SIGTERM（比如进程僵死、未正确处理信号、或 shell 占据 PID 1 导致信号丢失），再启用强制手段：
- docker kill <container> 直接发 SIGKILL，不可捕获，立即终结进程
- 等效写法：docker stop -t 0 <container>（把优雅等待设为 0 秒）
- 注意：可能造成未写入磁盘的数据丢失、连接中断、文件损坏，生产环境慎用
- 若需批量强杀：docker kill $(docker ps -q)
排查为什么停不下来
如果 docker stop 卡住或超时后仍没退出，常见原因有：
- 应用未监听 SIGTERM（尤其 Shell 启动的 Java/Go 进程，需用
exec方式启动以确保 PID 1 是业务进程） - 主进程被子进程阻塞，或存在孤儿进程未回收
- 挂载了 NFS 或异常存储卷，导致 umount 超时
- 查看容器实际退出码：docker ps -a 中 STATUS 显示 Exited (137) 就是被 SIGKILL 终止的典型标志
