Exited容器未删除时文件系统和环境完整保留，可先用docker ps -a查退出码定位异常，再通过docker commit生成调试镜像并运行shell检查；还可复现崩溃过程、挂载日志、启用调试器，并检查/proc/1/stack、配置挂载及依赖连通性。

容器Exited后，只要没被删除（docker rm），其文件系统和运行时环境依然完整保留在本地。这是调试崩溃容器最直接、低成本的切入点。

查看Exited容器的残留状态

用 docker ps -a 找到状态为 Exited 的容器，重点关注 STATUS 列中的退出码（如 Exited (1) 2 minutes ago）——它能快速提示错误类型（0=成功，非0=异常终止）。同时记下容器ID或名字，后续所有操作都基于它。

进入已停止容器的文件系统

Docker 不允许直接 exec 进入已退出容器，但可通过 docker commit 快速生成一个可交互的镜像：

• docker commit debug-snapshot —— 将当前容器的完整文件系统保存为新镜像
• docker run -it --rm debug-snapshot /bin/sh —— 启动临时容器并进入 shell，查看日志、配置、临时文件等

若原容器使用了自定义 entrypoint 或复杂启动逻辑，可在 run 时覆盖：--entrypoint /bin/sh，跳过原启动脚本直接获得控制权。

复现并捕获崩溃现场

单纯看文件系统有时不够，需让程序再次运行并观察失败过程：

• 用 docker run -it --rm --name test-run debug-snapshot 启动新容器，加上 -v $(pwd)/logs:/app/logs 挂载日志目录，便于收集输出
• 添加 --log-driver json-file --log-opt max-size=10m 确保标准输出/错误不丢失
• 对支持调试的程序（如 Python、Node.js），可挂载源码并启用调试器，例如：在 Python 容器中运行 python -m pdb app.py

检查关键运行上下文

很多 Exited 问题源于环境缺失或权限异常，重点检查：

• /proc/1/stack 和 /proc/1/status（在新启动的调试容器中读取，需用 --privileged 或 --cap-add=SYS_PTRACE）——可判断是否因 OOM 被杀或卡死在内核态
• 配置挂载是否生效：ls -l /etc/config、env | grep -i db
• 依赖服务连通性：telnet host.docker.internal 5432（macOS/Windows）或 nc -zv postgres 5432（Linux）