docker部署应用失败的核心原因有三：镜像构建不可复现、端口映射不匹配应用监听地址、容器内进程未以pid 1前台持续运行；任一出错将导致容器秒退或无法看到。
直接上结论：Docker部署应用不是“装完就跑”，核心卡点在镜像构建是否可复现、端口映射是否匹配应用实际监听地址、以及容器内进程是否真正作为 PID 1 持续运行。三者任一出错，docker run 后 docker ps 看不到容器，或容器秒退。
docker build 构建失败的常见原因
构建中断往往不是语法错误，而是网络、权限或路径问题。
-
Dockerfile中COPY或ADD的源路径必须相对于构建上下文（build context），不能写绝对路径如/home/user/app；若执行docker build -f ./Dockerfile .，则.是上下文根，所有COPY路径都从这里算起 - 国内环境拉取基础镜像（如
ubuntu:22.04、python:3.11-slim）超时，需提前配置镜像加速器，修改/etc/docker/daemon.json加入"registry-mirrors"字段，改完必须sudo systemctl restart docker - 执行
RUN apt-get install或pip install时因缓存或网络失败退出，建议加&& apt-get clean -y && rm -rf /var/lib/apt/lists/*清理，并用--no-cache-dir避免 pip 缓存干扰
docker run 启动后容器立即退出
这是最常被忽略的问题：容器生命周期由 CMD 或 ENTRYPOINT 指定的进程决定，该进程必须前台运行、不 daemon 化、且不能是 shell 脚本里最后一条无阻塞命令。
- Web 应用（如 Flask、FastAPI）默认监听
127.0.0.1:8000，但容器内必须绑定0.0.0.0:8000，否则外部无法访问，且部分框架（如某些 Gunicorn 配置）会因无法绑定而静默失败退出 - 使用
python app.py启动时，确认app.py内没有sys.exit()或未捕获的异常；加|| tail -f /dev/null是临时调试手段，但非正解 - 避免在
ENTRYPOINT中用sh -c "xxx"包裹命令——这会让 shell 成为 PID 1，而真正服务进程变成子进程，一旦子进程退出，shell 不自动退出，导致docker ps显示运行中但实际服务已挂
端口不通的典型排查路径
宿主机能 ping 通容器 IP，但 curl localhost:8000 失败，问题大概率不在网络驱动，而在映射逻辑或应用自身。
- 检查
docker run -p参数格式：必须是-p HOST_PORT:CONTAINER_PORT，顺序反了（如写成-p 8000:80但容器监听的是 8000）会导致映射失效 - 确认容器内应用真实监听端口：进入容器执行
netstat -tuln | grep :8000或ss -tuln | grep :8000，而不是只信文档或启动日志 - 防火墙干扰：CentOS/RHEL 默认启用
firewalld，即使docker run -p成功，宿主机防火墙也可能拦截HOST_PORT；临时关闭验证：sudo systemctl stop firewalld - Docker 默认使用
bridge网络，容器 IP 对宿主机不可直接路由；必须通过-p映射或--network host（不推荐用于生产）才能从宿主机访问
真正麻烦的从来不是命令敲不对，而是容器进程退出后没日志、端口监听了却连不上、镜像构建成功但换台机器就失败——这些都需要你习惯性查 docker logs -f <container_id></container_id>、进容器用 ps aux 看进程树、用 docker inspect 看网络和挂载细节。别依赖“应该可以”。
