docker kill 默认向容器pid 1进程发送不可捕获的sigkill（信号9），立即强制终止，不给清理机会；仅适用于docker stop超时、进程挂起或服务不可达等无响应场景，使用后须立即inspect查退出码（如137）并分析logs根治。
直接用 docker kill 就能强行终止容器进程，但它不是“随便一敲就完事”的操作——关键在于理解它发的是什么信号、什么时候该用、以及关掉之后必须做什么。
它到底做了什么？
docker kill 默认向容器的 PID 1 进程发送 SIGKILL（信号 9），这个信号无法被捕获或忽略，内核会立刻终止进程，不给任何清理机会。相当于直接拔电源，而不是按关机键。
- 它不等容器自己反应，也不走优雅退出流程
- 效果等同于在宿主机上执行
kill -9 - 如果你只是想让程序“正常收尾”，应该优先用
docker stop
什么时候才该用 docker kill？
只在容器真正僵死、无响应时动用：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
-
docker stop执行后超过 10 秒仍卡在Up状态 -
docker exec -it xxx sh进不去，或进去后命令无响应 -
docker logs -f完全没新输出，但docker inspect显示还在 running - 服务已不可达，CPU 和网络活动都为 0
怎么正确执行？
最常用也最稳妥的方式是按容器名或 ID 发送默认 SIGKILL：
- 按名称：
docker kill my-app - 按 ID 前几位：
docker kill a1b2c3 - 批量杀所有运行中容器：
docker kill $(docker ps -q) - 明确指定信号（可选）：
docker kill -s SIGKILL my-app或docker kill -s 9 my-app
注意：-s SIGTERM 也能用，但它只是“建议退出”，如果程序不响应，kill 不会再补一刀——这和 docker stop 的行为不同。
杀完之后不能不管
强制终止只是应急手段，关掉后必须立刻排查原因，否则重启还会挂：
- 查退出状态：
docker inspect my-app | grep -E "(ExitCode|OOMKilled|Error)"，重点关注是否为137（被 OOM killer 杀掉）、1（应用崩溃）或空错误 - 看日志线索：
docker logs --tail 50 my-app，找最后几行异常堆栈或卡点 - 根治方向：确认 PID 1 是否能响应 SIGTERM、是否设了合理内存 limit、是否存在阻塞 I/O 或死锁
