直接用 docker kill 就能强制终止死锁容器，但它不是“杀进程”，而是向容器主进程（PID 1）发送 SIGKILL 信号；仅当 docker stop 超时、exec 进不去、logs 无输出但状态仍为 running 时才使用，终止后须立即 inspect 查 ExitCode 137 等原因并分析 logs 定位阻塞点。
直接用 docker kill 就能强制终止死锁容器，但它不是“杀进程”，而是向容器主进程（PID 1）发送信号。关键在于理解它作用的对象、触发条件和后续动作。
什么时候该用 docker kill 终止死锁容器
仅当容器已失去响应，且 docker stop 失效时才使用：
-
docker stop my-app执行后超 10 秒，docker ps中状态仍显示 Up -
docker exec -it my-app sh卡住或直接报错无法进入 -
docker logs -f my-app完全无新输出，但docker inspect my-app显示"Status": "running"，而服务实际不可达
正确执行强制终止命令
默认发送 SIGKILL（信号 9），立即结束，不等待清理：
- 按名称终止：
docker kill my-app - 按 ID 前几位终止：
docker kill a1b2c3d4 - 批量终止所有运行中容器：
docker kill $(docker ps -q) - 显式指定信号（非必需，但更清晰）：
docker kill -s 9 my-app或docker kill -s KILL my-app
终止后必须立刻排查原因
强制终止只是临时手段，不查根因，重启后大概率再次死锁：
- 查退出码和 OOM 标记：
docker inspect my-app | grep -E "(ExitCode|OOMKilled|Error)"，重点看是否为 137（内存被系统杀）或 1（应用崩溃） - 读最近日志线索：
docker logs --tail 100 my-app，关注 panic、timeout、connection refused、deadlock、no space left 等关键词 - 确认 PID 1 是否真正响应信号：检查 Dockerfile 启动命令是否用了
exec "$@"，避免sh -c "xxx &"导致主进程非 PID 1
避免反复死锁的关键设置
靠 docker kill 救火不如提前加固容器行为：
- 设合理的内存 limit，建议比压测峰值高 20%，防止触发内核 OOM Killer
- 检查应用是否存在阻塞点：DNS 超时未设 timeout、数据库连接池耗尽、互斥锁未释放、挂载卷只读导致日志写失败
- 确保容器未运行在磁盘满、inode 耗尽或 /tmp 满的宿主机上
