容器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 + 构建流程固化修复
