掌握Docker容器的关键在于理解“镜像→容器→状态流转→资源归属”主线：容器是可预测、可干预、可审计的进程实例，其生命周期涵盖创建、启动、监控、干预与清理四大核心环节。
掌握 docker 容器，关键不在命令数量，而在理解“镜像→容器→状态流转→资源归属”这条主线。容器不是黑盒，它是可预测、可干预、可审计的进程实例。下面从实际运维视角，拆解最核心的四个环节。
容器启动：run 是起点，但 create + start 更可控
日常用 docker run 最省事，但它把拉取镜像、创建、启动全包在一起，出错时难以定位。生产环境建议分两步：
- 先用 docker create 预配置：指定名称（
--name）、端口（-p）、挂载（-v）、内存限制（-m 512m）、重启策略（--restart=unless-stopped）等，容器处于created状态，不占 CPU，可反复检查配置 - 确认无误后，再执行 docker start 启动。这样即使启动失败，也能用
docker inspect查看完整配置，避免run失败后配置直接丢失
状态监控：ps -a 是基本功，inspect 是真相入口
docker ps 只显示运行中容器，容易漏掉“刚崩了”的服务。真正有效的排查始于：
-
docker ps -a：一眼看清所有容器——
created（建好没启）、exited (137)（被 OOM kill）、exited (1)（应用启动报错） -
docker inspect <容器名或ID>：重点看
State.Status、State.ExitCode、State.OOMKilled、NetworkSettings.Ports和Mounts，这些字段直接说明“它为什么没起来”或“它连在哪” - 配合 docker logs <容器名>（加
-t看时间戳，--tail 100看末尾日志），三者结合，90% 的启动失败问题当场定位
运行中干预：pause/unpause 不是玩具，stop/kill 有本质区别
暂停和停止常被混用，但场景完全不同：
-
docker pause：冻结所有进程（类似系统级
kill -STOP），内存不释放、网络连接不断开、文件句柄不关闭。适合紧急降载、临时隔离故障容器，且不影响其他容器 -
docker stop：发
SIGTERM，给应用 10 秒优雅退出时间（可加-t 30延长），之后才发SIGKILL。这是标准下线流程，确保数据库连接关闭、缓存刷盘等 -
docker kill：直接发
SIGKILL，进程立刻终止。仅用于stop失效、进程卡死、或测试强制中断场景
清理与回收：rm 不是终点，--rm 和 volume 才是重点
删容器只是表象，真正影响长期稳定的是残留资源：
- 用 --rm 启动临时容器（如调试、数据迁移）：容器退出即自动清理，避免
docker ps -a堆满exited状态 - 删除容器前，务必确认 volume 挂载点：用
docker inspect查Mounts字段。若用了-v /host/path:/container/path，删容器不会删宿主机目录；但若用了匿名卷（-v /data），容器删掉后卷就成孤儿，需定期用docker volume ls+docker volume rm清理 - 批量清理已退出容器：
docker container prune（安全）或docker rm $(docker ps -aq -f status=exited)（脚本常用）
