直接用 docker kill 可强制终止无响应的僵尸容器，但仅适用于 docker stop 超时、无法 exec 进入且日志完全停滞这三种卡死场景；它默认发送不可捕获的 SIGKILL（信号9），无清理机会，强杀后须立即检查退出码（如137）和日志定位根因。
直接用 docker kill 就能强制终止无响应的僵尸容器，但必须清楚它不是“万能重启键”，而是紧急断电式操作——只在真正卡死、docker stop 失效时才启用。
什么情况下才算“真卡死”，值得强杀？
别一见容器没退出就急着 kill。确认以下三点都成立再动手：
-
docker stop执行后超过 10 秒，容器仍显示Status: running（用docker ps查） - 无法进入容器：
docker exec -it <name> sh卡住、超时或直接报错 - 日志完全静止：
docker logs -f <name>没新输出，且服务端口已不可达（如 curl 返回 connection refused）
正确执行 docker kill 的方式
默认发的就是 SIGKILL（信号 9），无需额外参数，简洁可靠：
- 按名称杀：
docker kill my-nginx - 按 ID 前几位杀：
docker kill a1b2c3 - 批量杀所有运行中容器：
docker kill $(docker ps -q)
不推荐加 -s KILL 或 -s 9——纯属冗余，反而容易误导以为可换其他信号。
强杀之后必须做的两件事
kill 只是“止痛”，不是“治病”。立刻跟进排查，否则下次还会卡：
- 查退出码：
docker inspect <name> --format='{{.State.ExitCode}}'，若为137，说明确系被 SIGKILL 终止 - 看最后日志：
docker logs --tail 50 <name>，重点找 OOM killer 记录、阻塞调用（如read() on socket长时间不返回）、或未捕获的 panic
怎么避免反复强杀？治本的关键点
频繁 kill 本质是容器设计或配置有隐患：
- 确保 PID 1 进程能转发信号：启动时加
--init，或镜像里用tini作入口点 - 给容器设内存 limit：避免被系统 OOM killer 杀掉后残留僵死状态
- 应用代码里监听
SIGTERM：做连接关闭、临时文件清理等收尾动作，别让主进程无视信号
