容器启动失败应先查状态、再看日志、最后验证配置：用docker ps -a和inspect确认状态与退出码，docker logs查stdout/stderr，依ExitCode、端口冲突、挂载权限、配置错误等针对性解决。
容器出问题，别急着 exec 进去翻找——先看状态、再查日志、最后才动文件系统。核心是分清“容器是否在跑”：运行中的容器靠 logs 和 inspect 快速定位；已停止的容器不能直接进入，但能精准读日志、查退出码、挂载数据层。
第一步：确认容器当前状态和退出原因
运行以下命令，快速判断容器是“没启动”还是“刚崩了”：
-
docker ps -a | grep—— 查看 STATUS 列，如Exited (137)或Up 4 seconds (unhealthy) -
docker inspect --format='{{.State.ExitCode}} {{.State.Error}}'—— 直接提取退出码和错误信息，比翻长 JSON 更快 -
docker inspect --format='{{.State.Status}} {{.State.StartedAt}} {{.State.FinishedAt}}'—— 看启动/结束时间，判断是否频繁重启
常见退出码含义：0（正常退出，常因缺少前台进程）；1（应用报错或配置缺失）；137（内存超限被 OOM Killer 杀掉）；143（收到 SIGTERM 后优雅退出）。
第二步：优先查日志，80% 的问题这里就能闭环
不依赖容器内有没有 shell，纯靠宿主机命令即可获取关键线索：
-
docker logs—— 默认输出全部 stdout/stderr，适合首次排查 -
docker logs --tail 100 --since "5m"—— 只看最近 100 行或过去 5 分钟，避免刷屏 -
docker logs -f—— 若容器刚重启，加-f实时跟踪新日志（需配合docker start）
典型日志线索举例："failed to read config.yml: permission denied" → 挂载权限问题；"FATAL: password authentication failed" → 数据库密码错误；"Killed process … (oom_reaper)" → 明确指向内存不足。
第三步：容器无法启动或镜像无 shell？用调试容器绕过限制
当 docker exec 报 "sh: not found" 或容器一启动就退出，说明镜像太瘦、工具链缺失。此时不要换回带 shell 的镜像，而是临时起一个调试容器：
-
docker run -it --rm --volumes-from --entrypoint /bin/sh—— 复用原容器挂载卷，进新容器查配置文件 -
docker run -it --rm -v /var/lib/docker:/host-docker:ro alpine ls /host-docker/overlay2/—— 在 overlay2 存储驱动下，直接读取原容器可写层（需知道其目录 ID） - 若只缺网络诊断工具，可临时注入：
docker exec apt update && apt install -y curl net-tools（仅限 deb 系基础镜像）
第四步：辅助验证——网络、资源、配置是否到位
日志和状态都正常？继续往下挖：
-
docker port—— 确认端口映射是否生效，比如显示8080->0.0.0.0:8080才算成功绑定 -
docker stats --no-stream—— 查实时 CPU、内存、IO 使用率，识别资源瓶颈 -
docker inspect --format='{{.NetworkSettings.Networks.bridge.IPAddress}}'—— 获取容器 IP，再用curl http://测试服务是否真在监听: -
docker inspect --format='{{.HostConfig.RestartPolicy.Name}}'—— 检查重启策略是否为always或on-failure，避免误设成no导致崩溃后不重试
