docker创建容器后无法启动的排查与解决方法

刚敲完 docker run 或者 docker-compose up -d，满心期待服务跑起来，结果转头一看状态是 Exited (1) 或者干脆卡在 Created 不动弹。这种时候最搞心态，因为屏幕上往往没有直接的报错红字，只有一个冷冰冰的状态码。

别急着去搜“如何重装Docker”，绝大多数情况下，问题就藏在容器的标准输出日志里，或者是某个不起眼的配置项上。我们直接看最该先检查的地方。

1. 第一时间查看容器日志

容器起不来，最直接的原因通常是应用本身崩溃了。Docker 把应用的 stdout 和 stderr 都存了下来，这是破案的第一现场。

使用以下命令查看最近退出的容器日志：

docker logs <容器ID或名称>

如果日志太多，可以加 --tail 50 只看最后50行。你会看到类似 Error: listen EADDRINUSE 或者 Config file not found 这样的具体错误。如果是 Java 应用，可能是一长串 Exception；如果是 Nginx，可能是配置文件语法错误。

通过 docker logs 查看容器退出的具体报错信息

注意观察日志的最后几行。如果日志为空，说明应用甚至没开始运行就退出了，这通常指向权限问题或入口点（Entrypoint）配置错误。

2. 检查端口是否被占用

很多时候，容器启动失败是因为宿主机的端口已经被占用了。比如你想把容器的 80 端口映射到宿主机的 8080，但宿主机上已经有一个 Tomcat 或另一个 Docker 容器占用了 8080。

这种情况下，docker ps 看不到容器，因为它根本没启动成功。你可以尝试手动指定端口启动来测试：

docker run -p 8080:80 nginx

如果终端直接报错 Bind for 0.0.0.0:8080 failed: port is already allocated，那就实锤了。解决办法有两个：要么杀掉占用端口的进程，要么换一个宿主机端口，比如改成 -p 8081:80。

端口被占用时的典型报错提示

在 Windows 或 macOS 上，有时 Docker Desktop 的网络驱动会出现小故障，重启 Docker 服务也能解决一些诡异的端口绑定问题。

3. 核对环境变量与挂载路径

如果日志里提示“缺少配置”或“权限拒绝”，多半是启动参数没传对。很多镜像依赖环境变量来初始化数据库连接或 API 密钥。

检查你的 docker run 命令或 docker-compose.yml 文件：

• 环境变量：确认 -e KEY=VALUE 是否拼写正确，特别是大小写敏感的配置项。
• 挂载卷：如果你挂载了本地目录到容器内，确保宿主机路径存在，且 Docker 有读取权限。在 Linux 上，经常遇到因为文件所有权导致的 Permission denied。

检查环境变量和挂载路径配置

例如，MySQL 容器如果没设置 MYSQL_ROOT_PASSWORD，它会拒绝启动以保护安全。这时候日志里会明确写着 “Database is uninitialized and password option is not specified”。补上环境变量再试即可。

4. 资源限制与镜像架构

如果以上都没问题，还要看看是不是“硬伤”。比如给容器分配的内存太小，应用启动时直接 OOM（内存溢出）被杀掉了。可以通过 docker inspect <容器ID> 查看退出原因是否为 OOMKilled。

另外，如果你在 Apple Silicon (M1/M2) 电脑上运行专为 x86_64 构建的镜像，可能会因为架构不兼容导致启动缓慢或失败。确保拉取的镜像支持当前平台，或者在 Docker Desktop 中开启 Rosetta 转译支持。

排查这类问题，顺序很重要：先看日志定性质，再查端口和配置找细节，最后看资源和架构。大部分时候，读懂那几行报错日志，问题就解决了一半。