应先执行docker ps -a查看容器状态及退出码，再用docker logs命令查日志定位根因；Exited(1)多为配置或应用错误，Exited(137)表明内存超限被OOM Killer终止，日志为空则进程未执行即失败。
不能直接进入已停止或异常退出的容器——Docker 要求容器必须处于运行状态才能执行 docker exec。但你可以通过启动它再进入，或在不启动原容器的前提下“模拟访问”其文件系统。关键看你想查什么：日志、配置、文件，还是运行时环境？
先看状态和退出码，快速定位问题类型
运行以下命令，重点关注 STATUS 列和括号里的退出码：
-
docker ps -a—— 查所有容器，找到目标容器的 NAME 或 CONTAINER ID -
docker inspect <容器名或ID> | grep -A 5 "State"—— 精确查看退出码（ExitCode）、错误信息（Error）和终止原因
常见退出码含义：
0：主进程正常结束（常因缺少前台进程）
1：应用崩溃或配置错误
137：被 SIGKILL 终止（大概率内存超限 OOM）
143：收到 SIGTERM 后优雅退出（如手动 stop 或超时）
方案一：启动容器后进入（适合可安全重启的场景）
适用于容器镜像稳定、无副作用、且启动逻辑不会反复失败的情况：
-
docker start <容器名或ID>—— 启动容器（若启动即退出，说明问题仍在） -
docker exec -it <容器名或ID> /bin/sh（或/bin/bash，取决于镜像）—— 进入交互终端
⚠️ 注意：如果容器启动后立刻退出（比如 ExitCode=1），说明根本问题未解决，此时 exec 会失败。应优先查日志。
方案二：查日志，不进容器也能定位 80% 的问题
绝大多数启动失败或异常退出的问题，日志里已有明确线索：
-
docker logs <容器名或ID>—— 查 stdout/stderr 输出 -
docker logs --tail 100 --since "10m" <容器名或ID>—— 只看最近 100 行，或过去 10 分钟内日志 -
docker logs -f <容器名或ID>—— 若容器刚重启，可用 -f 实时跟踪（需配合重新启动）
典型线索示例：
"failed to open config.yaml: no such file" → 挂载路径错误
"Address already in use" → 端口冲突
"npm ERR! missing script: start" → 启动命令配置错误
方案三：不启动原容器，临时挂载其文件系统（适合启动即崩、权限受限等高危场景）
当容器无法安全启动（如数据库损坏、配置严重错误），又需要读取内部文件时，可用此法：
- 用相同镜像创建一个新容器，并挂载原容器的可写层（overlay2 存储驱动下）：
docker create --name temp-debug -it <原镜像名> /bin/sh - 复制原容器的根文件系统到新容器中（需 root 权限）：
docker export <已停止容器ID> | docker import - debug-img
或更轻量方式：docker run -it --rm -v /var/lib/docker:/host-docker alpine ls /host-docker/overlay2/<原容器layer-id>/diff（需先查 layer ID） - 实际中更推荐：
docker run -it --rm -v $(pwd)/config:/app/config:ro <镜像名> cat /app/config/app.conf—— 直接用新容器读取你关心的宿主机映射文件
这个方法绕过原容器生命周期，安全读取静态内容，适合生产环境紧急排查。
