容器本质是前台进程，其生命周期由pid 1进程决定；docker run创建并启动容器，docker start仅重启已存在容器；容器秒退主因是pid 1进程退出，需确保其为持续运行的前台服务。
启动 docker 容器不是简单敲一条 docker run 就完事——它背后是进程生命周期、前台守护逻辑和资源隔离的综合体现。真正用好，关键在于理解“容器即进程”这一核心：容器不会自己一直运行，它只活在主进程（pid 1）存续期间。
启动容器的两种路径：run 和 start
很多人混淆“新建并运行”和“重启已存在容器”，其实这是两个独立操作：
-
docker run：一次性完成三件事——拉镜像（如本地没有）、创建容器、启动容器。适合首次部署或临时测试，例如：
docker run -d --name my-redis -p 6379:6379 redis:7.2 -
docker start：仅针对已存在但处于
Exited状态的容器。它不重建文件系统，只恢复进程空间，适合反复调试配置后的复用，例如：docker start my-redis
注意：docker run 加 -d 是后台运行；不加则前台阻塞终端，适合调试命令是否能正常执行（比如 docker run ubuntu:22.04 ls /）。
为什么容器秒退？必须守住“前台进程”
很多新手遇到 docker run centos:7 启动后立刻退出，根本原因是：CentOS 镜像默认 CMD 是 /bin/bash，而 bash 没有交互终端时立即退出，导致 PID 1 消失，容器终止。
解决方法不是“让它别退”，而是给它一个持续运行的前台进程：
- 用
-it提供伪终端（适合调试）：docker run -it centos:7 /bin/bash - 用
tail -f /dev/null占位（适合生产轻量守护）：docker run -d centos:7 tail -f /dev/null - 用服务类命令直接前台启动（推荐）：
docker run -d nginx（Nginx 默认前台运行）docker run -d mysql:8.0（mysqld_safe 默认前台）
查进程、进容器、看日志：三位一体排错法
容器跑起来≠服务就通了。日常排查建议按顺序做三件事：
-
看容器状态：
docker ps查运行中容器；docker ps -a查所有容器（含已退出的），确认是否卡在Created或Exited (1) -
进容器看真实进程：
docker exec -it ps aux—— 检查 PID 1 是否是你期望的进程（如nginx: master process），而不是sh或空跑的sleep -
盯日志输出：
docker logs查启动日志；加-f实时跟踪：docker logs -f my-app—— 90% 的配置错误（端口冲突、配置文件缺失、权限问题）都会在这里暴露
后台运行与资源控制：别让容器失控
用 -d 启动只是第一步。真正稳定运行还需基础约束：
-
限制内存和 CPU，防止单个容器吃光宿主机资源：
docker run -d --memory=512m --cpus=1.0 nginx -
设置自动重启策略，应对意外崩溃：
docker run -d --restart=unless-stopped nginx（推荐开发/测试）docker run -d --restart=on-failure:3 nginx（适合有明确失败重试场景） -
指定清理策略，避免停用容器堆积：
docker run -d --rm nginx—— 容器退出后自动删除，适合一次性任务
