强制终止容器
docker kill 向容器内主进程发送信号，默认是 SIGKILL，也就是强制终止：没有优雅退出过程，不做连接收尾，也不等数据落盘。它适用于进程僵死、docker stop 超时仍不退出、以及内核态不可中断状态导致进程无法响应信号等极端情况。日常停容器应优先使用 docker stop，让应用有机会自己结束。
基本信息
| 默认信号 | SIGKILL，进程立即终止，没有清理机会 |
|---|---|
| 指定信号 | -s SIGTERM 等可自定义；但发 SIGTERM 本来就该用 docker stop |
| 适用场景 | stop 超时仍不退、句柄僵死、需要立刻止血的应急情况 |
| 直接后果 | 连接硬断，未落盘的数据可能丢失 |
| 查看结果 | docker inspect 看 State.ExitCode 与 OOMKilled 字段 |
| 对比命令 | docker rm -f 相当于终止后直接删除容器，容器内改动一并消失 |
典型使用场景
- 应用僵死且 docker stop 已超时仍未退出
- 容器内句柄泄漏导致进程无法被常规信号终止
- 应急止血：进程持续冲击宿主资源，需要立刻停下
- 调试过程中快速清理实验容器，其数据不涉及持久化
- 批处理容器的清理，前提是结果已落盘到卷或对象存储
使用示例
使用示例
docker kill myapp # 默认发 SIGKILL
docker kill -s SIGTERM myapp # 自定义信号的少见用法
docker stop -t 30 myapp # 优先用 stop，给 30 秒优雅窗口
docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' myapp # 看退出码与 OOM
docker events --filter container=myapp --since 10m # 回看容器生命周期事件退出码读法
| 退出码 | 含义 | 常见原因 |
|---|---|---|
| 0 | 正常退出 | 进程自身执行完毕 |
| 137 | 128+9，被 SIGKILL 终止 | 手工 kill、stop 超时强杀、内存超限 OOM |
| 143 | 128+15，被 SIGTERM 终止 | 优雅停止，属正常路径 |
| 125 | docker 自身报错 | 参数或镜像问题，容器并未真正启动 |
| 126 与 127 | 命令不可执行或找不到 | 入口脚本、可执行权限或路径问题 |
kill 之后容器状态变成 Exited，用 docker inspect 看 ExitCode 判断原因：137 不必然等于 OOM，也可能是手工 kill 或宿主内存压力导致的强杀，需要结合 OOMKilled 字段与内核日志区分。
对数据库、消息队列这类带写缓冲的进程，SIGKILL 会跳过刷盘与连接收尾，可能引入数据不一致。这类容器只在确认僵死且常规停止无效时使用 kill，事后按恢复流程校验数据完整性。