容器起不来绝大多数情况下是配置错误、资源不足、启动命令处理不当或镜像本身问题造成的，排查时优先看容器日志和系统资源状态，顺序对了解决速度能快不少。
为什么我的容器总是起不来？常见原因与排查方向
容器启动失败的现象五花八门,但背后原因往往集中在几个常见区域，从我的经验看，80% 的失败都可以归到配置、资源、进程和镜像这四类，下面按出现频率由高到低拆开讲。
docker容器启动失败原因详解：配置错误与依赖缺失
配置问题是最容易踩的坑,新手和老手都难免，具体表现包括端口映射冲突、环境变量未正确传递、卷挂载路径不存在或权限不足、网络模式选择错误等。
- 端口映射冲突：容器要绑定的宿主机端口已经被其他进程占用，导致启动时直接报错
port is already allocated，建议启动前用netstat -tuln | grep <端口号>确认端口空闲，或者使用随机端口-P暂时代替。 - 环境变量与配置文件：很多镜像依赖
-e传入的环境变量，比如数据库密码、API 密钥，如果漏传或传错，容器内的应用会立即退出，排查时用docker inspect查看Env字段，确认值是否正确。 - 卷挂载问题：挂载的宿主机目录不存在或权限为 root，会导致容器内进程无法写入，常见错误信息“permission denied”或“cannot access ...”，建议先创建好目录，并用
Z或z处理 SELinux 标签（如果启用）。 - 网络模式冲突：使用了
--network host但同时又绑定了端口，或者自定义网络与全局网络同名，都会导致启动失败，推荐使用docker network ls查看已有网络，避免名称重复。
容器服务启动异常排查步骤：从日志到系统资源
当容器无法启动时,第一步永远是看日志，而不是盲目重启，下面是一套标准化的排查流程，适合生产环境容器启动失败时使用。
- 检查容器状态：
docker ps -a列出所有容器，关注 STATUS 列，常见状态有Exited (0)表示正常退出，Exited (非0)表示异常退出，Created表示未启动，Restarting表示不断重启。 - 查看容器日志：
docker logs <容器名或ID>直接输出最新日志，如果日志太长，加--tail 50只看最后50行，或--since 5m只看最近5分钟。 - 检查容器配置：
docker inspect <容器名>
输出完整 JSON 配置，重点看
HostConfig、Mounts、Env和PortBindings。 - 检查系统资源：
docker system df查看 Docker 使用的磁盘空间，df -h查看宿主机磁盘，free -h查看内存，top -bn1 | grep -i cpu查看 CPU 负载。 - 检查 Docker 守护进程日志：
journalctl -u docker -n 50或查看/var/log/docker.log，有时底层错误不会体现在容器日志里。
资源限制导致容器无法启动
资源不够是第二个高频原因,尤其在机器配置不高或同时运行多个容器的场景下。多数情况下，容器启动失败的直接原因是磁盘空间不足或内存耗尽。
内存与 CPU 分配不足
如果容器内的应用对内存需求较大,但启动时没有设置 --memory 限制或者限制得过小，内核会触发 OOM（Out Of Memory）杀死进程，容器状态会显示 Exited (137) 或 OOMKilled。
- 现象：容器启动后几秒内退出，日志里可能没有错误，或者出现
Killed字样。 - 解决：逐步增加内存限制，
-m 512m、-m 1g，同时观察docker stats中的实际使用量，如果宿主机内存本身不足，需要先关闭其他进程或扩容。 - CPU 资源不足通常不会直接导致启动失败，但会让容器启动非常慢，甚至超时，可以用
--cpus限制 CPU 使用，但一般不建议设置过小。
磁盘空间不足引发“no space left on device”
这是非常经典的报错,Docker 的镜像层、容器层、日志文件都存储在 /var/lib/docker 下，如果该分区被写满，任何写操作都会失败。
- 常见场景：日志未清理、镜像缓存过多、容器日志回滚未配置。
docker system prune -a可以清理闲置镜像、容器和网络，但要注意会删除所有未使用的资源。 - 预防：配置日志轮转，在启动容器时加
--log-opt max-size=10m --log-opt max-file=3，限制单个日志文件大小和保留个数。 - 检查命令：
docker system df -v可以查看每个镜像和容器占用的空间，du -sh /var/lib/docker/containers看容器日志总量。
容器启动后立即退出？进程管理与前台运行误区
很多人在 Dockerfile 里写 CMD 或 ENTRYPOINT 时，习惯用启动后台服务的命令，systemctl start 或 service nginx start。容器本质上是一个进程，必须在前台运行，否则启动后会立即退出
。
- 错误做法：
CMD ["systemctl", "start", "nginx"]，这条命令会启动后台守护进程，然后立即返回，容器认为任务完成就退出。 - 正确做法：直接运行 nginx 的前台进程，
CMD ["nginx", "-g", "daemon off;"]，或者CMD ["npm", "start"]，对于多进程需求，建议使用supervisord或tini作为 init 进程。 - 排查技巧：当容器启动后立即变成
Exited (0)，说明进程正常退出，大概率是命令写成了后台模式，如果退出码非0，则说明应用本身报错，需要看日志。
镜像与仓库问题
镜像本身的问题不常发生,但一旦出现，排查起来可能绕弯路。镜像拉取失败、镜像损坏、版本不兼容都有可能让容器起不来。
- 拉取失败：
docker pull超时、仓库认证失败、镜像 tag 不存在，国内环境建议配置镜像加速器，如https://docker.mirrors.ustc.edu.cn（中科大源）或简米云加速器，如果遇到unauthorized: authentication required，记得先docker login。 - 镜像损坏：网络传输中断可能导致镜像层不完整，拉取后启动报错，可以尝试重新
docker pull或者清理本地缓存后重试。 - 版本不兼容：应用依赖的库版本与镜像内的操作系统版本不匹配，比如在 Alpine 镜像里尝试运行需要 glibc 的程序，会报
not found错误，建议使用官方镜像，或根据基础镜像重新构建。 - 镜像体积过大：虽然不直接导致启动失败，但拉取和启动时间过长，容易让用户误以为容器卡住了，可以用
docker history查看镜像分层，优化不必要的层，或者使用更轻量的基础镜像，如alpine、slim版本。
生产环境容器启动失败怎么办？系统级排查思路
生产环境比本地开发多了一层调度和网络限制,Kubernetes、服务网格、安全策略等。Kubernetes 中 Pod 状态 CrashLoopBackOff 最常见，原因和 Docker 类似，但排查路径略有不同。
- 查看 Pod 状态：
kubectl get pods查看所有 Pod 的 STATUS 列。CrashLoopBackOff表示容器不断重启，ImagePullBackOff表示镜像拉取失败，CreateContainerConfigError表示配置错误。 - 查看 Pod 日志：
kubectl logs <pod-name> -c <container-name>只看某个容器的日志，Pod 正在重启，加--previous
可以查看上一次崩溃的日志。
- 查看 Pod 事件：
kubectl describe pod <pod-name>中的 Events 部分会记录拉取镜像、挂载卷、启动失败等详细原因，是排查的第一手资料。 - 系统级资源：
kubectl top nodes查看节点资源使用率，kubectl top pods查看 Pod 资源使用，如果节点资源不足，Pod 可能被 Evict 或无法调度。 - 网络策略：某些安全组或网络策略会阻止容器访问外部服务，导致应用启动失败，可以临时在同一个 Namespace 下启动一个测试 Pod 来验证连通性。
容器起不来的原因并不复杂,配置错误和资源不足是最常见的两类。记住一个原则：先看日志，后看资源，最后检查配置，不要一上来就重启或重新创建，那样只会掩盖真正的错误，无论是本地开发还是生产环境，按照上述步骤逐一排查，90% 的问题都能在五分钟内定位。
常见问题解答
容器启动一直显示 Creating 状态是怎么回事？
这通常表示 Docker 守护进程正在执行创建容器所需的操作，比如拉取镜像、分配存储、设置网络等，如果停留在 Creating 超过几分钟，可能是镜像拉取速度过慢或磁盘 I/O 阻塞，建议先检查网络连接和镜像源，同时用 docker system df 确认磁盘空间是否充足，并用 docker events 实时查看守护进程事件，看是否有异常报错。
Docker 容器启动后马上退出，没有日志怎么办？
容器启动后立即退出且日志为空,多半是应用进程在启动时直接崩溃，但日志被冲刷了，首先尝试 docker logs --tail 100 --timestamps <容器名> 获取精确时间戳，有时日志在退出前已写入，如果依然空白，检查 Dockerfile 中的 CMD 或 ENTRYPOINT，确保进程在前台运行，另外可以在本地用 docker run -it <镜像名> sh 交互式启动，手动执行启动命令，查看实时输出，这是最直接的定位方式。
生产环境容器启动失败，如何快速区分是应用问题还是容器环境问题？
先看退出码,退出码 0 表示正常退出，通常是启动命令不当（如后台运行）；退出码 137 表示被 OOM 杀死，是资源问题；退出码 139 表示段错误，可能是应用兼容性问题，然后看 Pod 或容器的事件，Events 里出现 FailedCreatePodSandBox 或 NetworkPluginNotReady，说明是容器运行时或网络环境问题，与应用代码无关，Events 正常但容器不断重启，再用 kubectl logs --previous 查看应用日志，定位具体异常。