docker stop 是优雅关闭，先发 SIGTERM 给 PID 1 进程并默认等待 10 秒，超时再发 SIGKILL；docker kill 默认直发 SIGKILL，无清理机会。真正优雅需应用响应 SIGTERM、前台运行 PID 1、合理设置超时。
容器停止时用 docker stop 是优雅关闭，会先发 SIGTERM 信号给主进程，等待其自行清理后退出；超时未退出才发 SIGKILL 强制终止。而 docker kill 默认直接发 SIGKILL，跳过清理阶段，属于强制结束。
docker stop 的工作流程
执行 docker stop 时，Docker 引擎会：
- 向容器内 PID 1 进程发送
SIGTERM信号，给予默认 10 秒（可自定义）的宽限期 - 若进程在时限内主动退出，容器状态变为
exited，整个过程视为优雅关闭 - 若超时仍未退出，Docker 自动补发
SIGKILL强制终结进程 - 该机制依赖应用自身对
SIGTERM的响应能力——比如 Web 服务应拒绝新请求、完成正在处理的请求后再退出
docker kill 的行为特点
docker kill 默认不等待，直接向容器主进程发送 SIGKILL（也可指定其他信号，如 -s SIGTERM）：
- 进程无法捕获或忽略
SIGKILL，立即终止，无机会执行清理逻辑 - 文件写入可能中断、数据库连接未释放、临时文件残留、socket 未正确关闭等风险较高
- 适合卡死、无响应或调试场景，但生产环境应避免随意使用
如何让 stop 真正“优雅”起来
仅靠 docker stop 不够，还需容器内应用配合：
- 主进程必须是前台运行的 PID 1（避免被 shell 封装导致信号转发失败）
- 代码中监听
SIGTERM，实现资源释放、平滑下线等逻辑（如 Go 的signal.Notify、Node.js 的process.on('SIGTERM')） - 必要时在
Dockerfile中用STOPSIGNAL SIGTERM显式声明期望信号 - 通过
docker stop -t 30 myapp延长超时时间，适配慢速清理场景
常见误操作与建议
实际使用中容易混淆或踩坑：
- 用
docker kill替代stop处理日常停机——应优先用stop，仅在stop超时失败后考虑kill - Java 应用未配置 JVM 参数（如
-XX:+UseContainerSupport）导致无法响应信号——需确保 JVM 正确传递 OS 信号 - 容器内启动了多个进程且未用
init系统（如tini），导致子进程收不到信号——推荐在ENTRYPOINT前加入轻量 init - 误以为
docker stop总是立即生效——其实它有等待逻辑，可通过docker ps -a观察状态变化
