容器Exited后不能直接重启，须先查日志和退出码定位原因（如137为OOM、139为段错误），再针对性修复配置、端口、权限或依赖，必要时进入调试或重建镜像。

容器Exited后不能直接“重启”，必须先分析退出原因，再决定是重新运行、修复配置，还是进入容器调试。盲目执行 docker start 往往失败或启动后立即退出。

查清Exited原因

容器退出后，首要动作是查看日志和退出码：

• 看日志：docker logs <container_id></container_id> —— 检查应用崩溃、配置错误、端口占用、依赖缺失等关键线索
• 看退出码：docker inspect <container_id> | grep -i "status\|exit"</container_id> —— 状态为 exited (1) 表示应用层报错；exited (137) 多因 OOM 被 kill；exited (139) 常见于段错误（如 C 扩展崩溃）
• 确认是否曾被手动 stop 或 kill：用 docker ps -a 查看 STATUS 列，带 “(Exited … seconds ago)” 的通常是正常终止；若无时间提示，可能是异常中断

临时进入已停止容器调试（仅限支持 shell 的镜像）

某些镜像（如官方 Ubuntu/Alpine/Nginx:alpine）仍允许挂载新进程进入已停止容器，用于检查文件、环境变量或手动启动服务：

• 执行：docker start <container_id> && docker exec -it <container_id> /bin/sh</container_id></container_id>
• 若容器启动即退，可尝试覆盖入口命令：docker run -it --volumes-from <old_container> --rm <image_name> /bin/sh</image_name></old_container>，复用原卷快速诊断
• 注意：该方法不适用于无 shell 的精简镜像（如 scratch 基础镜像）或设置了 ENTRYPOINT ["app"] 且无法覆盖的场景

重建容器前的关键修复点

多数 Exited 问题源于启动时配置或依赖缺失，需针对性修正后再 docker run：

• 检查端口冲突：宿主机端口已被占用？用 lsof -i :8080 或 netstat -tuln | grep :8080 确认
• 验证挂载路径权限与存在性：宿主机目录不存在、权限不足（尤其在 SELinux 或 rootless Docker 下）、或 bind mount 路径写反（如把容器内路径当宿主机路径）
• 确认环境变量与配置文件：通过 docker inspect 查 Config.Env 和 Mounts，比对实际所需变量（如 DB_HOST、CONFIG_PATH）是否传入正确
• 测试镜像基础可用性：先运行最小实例：docker run --rm -it <image> sh -c 'echo ok'</image>，排除镜像本身损坏或 ENTRYPOINT 错误

用 docker commit 保存临时修复（慎用）

仅当需快速保留某次手动修复状态（如改了配置文件、装了调试工具），且不便于改 Dockerfile 时使用：

• 启动容器 → 进入修改 → docker commit <container_id> my-fix:latest</container_id>
• 后续用新镜像运行：docker run -d --name fixed-app my-fix:latest
• 警告：commit 生成的镜像是黑盒，不可追溯、难复现、不推荐用于生产；应优先通过 Dockerfile + 构建流程固化修复