3.1 容器生命周期命令词条：create 到 rm 的全套动词
3.1 容器生命周期命令词条：create 到 rm 的全套动词
本节摘要：容器的一生由一组动词驱动：create 创建、start 启动、stop 优雅停止、kill 强杀、pause 暂停、restart 重启、rm 删除。本节给全这组词条的语法与义项，用状态板把"哪个动作改变哪个状态"钉牢，并逐个拆解 stop 与 kill 的信号差异、rm 的引用检查等高频坑点。
叁部从"容器的生老病死"讲起。测试环境里那只反复重启的容器、删除时报的 conflict、stop 之后进程还赖着不走的尴尬，全都能在生命周期词条里找到出处。先把状态板立起来，后面每个动词都对号入座。
状态板：容器的一生
每个动词都是状态之间的一条边。命令组如下：
docker create [OPTIONS] IMAGE [COMMAND] # 创建容器，停在 created docker start 容器 # created/exited → running docker run [OPTIONS] IMAGE [COMMAND] # create + start 合体 docker stop 容器 [-t 秒] # 优雅停止：先 SIGTERM，超时 SIGKILL docker kill 容器 [-s 信号] # 直接发信号，默认 SIGKILL docker pause / unpause 容器 # 冻结与解冻，状态 paused docker restart 容器 [-t 秒] # stop 再 start 的组合动作 docker rm 容器 [-f] [-v] # 删除容器，须先退出 running
词条现场：stop 与 kill 的信号差别
同样是"让容器停下来"，stop 与 kill 的内在动作完全不同，这个差别在生产事故里反复被验证：
$ docker stop web web $ docker kill web --signal=SIGTERM # kill 也能指定信号 web
stop 走的是体面流程：先向容器主进程发 SIGTERM，给它收拾善后的机会（落盘、关连接、写退出日志），默认等十秒；进程还没退，再补 SIGKILL 强制了断。-t 可以改这个等待时长。kill 则跳过寒暄，默认直接 SIGKILL——进程没有任何机会执行清理逻辑。所以有一条铁律：能 stop 就 stop，kill 留给 stop 不动或需要立即处决的场景。数据库容器用 kill 对付，相当于直接拔电源，恢复时的代价自己想。
pause 是另一回事：它不发任何信号，而是冻结进程调度，容器内存原样保留，unpause 后从冻结点继续。适合"短暂让路"的场景，比如先把批处理容器按住，等白天高峰过了再放行。
词条现场：rm 的引用检查与批量清理
$ docker rm web Error response from daemon: cannot remove container "/web": container is running: stop the container before removing $ docker rm -f web web
rm 对 running 状态的容器同样设了门，-f 会先 kill 再删。手动运维里更推荐分开写 stop、rm，中间留一次确认机会；-f 适合脚本里明确知道后果的场合。高频搭配还有两个：
$ docker rm -v web # 连同匿名卷一起删，防止卷残留 $ docker container prune # 批量清掉所有 exited 容器 WARNING! This will remove all stopped containers. Are you sure you want to continue? [y/N] y Deleted Containers: 9f2c41a7b110 5e81c3a2b7f0 Total reclaimed space: 44.2MB
-v 的意义在伍部会展开：匿名卷不随容器删除而消失，会变成无主卷占着磁盘。container prune 则是测试环境的常客——CI 跑完一轮留下的尸体一扫而空。注意它只清 exited，不碰 running 与 created；想连 created 的半成品一起处理，得点名 rm。
词条现场：restart 与重启策略的关系
$ docker restart web web $ docker inspect web --format '{{.State.Status}} {{.RestartCount}}' running 3
restart 命令是人主动按的重启按钮；而 --restart 策略（3.2 详解）是容器异常退出时守护进程的自动行为，两者互不替代。RestartCount 累计的是自动重启的次数——它持续增长而 Status 又不停在 restarting，就是捌部要处理的"重启风暴"信号，本节先记住这个字段在哪看。
⚠️ 常见坑：stop 之后容器进入 exited 而不是消失，docker ps 默认看不到它，于是有人以为"停了就没了"，等发现磁盘被一堆 exited 容器占满时已经积攒了成百上千具尸体。验收容器是否停止，用
docker ps -a --filter status=exited。
状态疑难：三类"卡住"的现场处置
生命周期词条的求助帖里，卡住比崩溃更常见。按状态归位，处置各有一套：
卡在 created。docker ps -a 里状态长期是 Created，start 也没反应。常见根因是入口配置有误——镜像没有可执行文件、或 run 时给的 COMMAND 路径不存在，容器在建时就注定起不来。取证靠 inspect 的 State.Error 字段，十有八九直接写着可执行文件路径的问题：
$ docker start ghost ghost $ docker inspect ghost --format '{{.State.Status}} {{.State.Error}}' created exec: "no-such-bin": executable file not found in $PATH
处置就一步：rm 掉这个容器，修好镜像或命令参数重新 run。created 容器不占运行资源，但会占用名字与网络端点，别让它长期滞留。
卡在 restarting。RestartCount 一路涨、状态不停在 restarting 与 exited 之间横跳。这是重启风暴：容器主进程秒退，重启策略（3.2 的 --restart）不停拉起。问诊顺序照捌部的路径走，但止血动作现在就能给：先 docker stop（stop 对 restarting 状态同样有效），让它安静下来再慢慢查日志。
卡在 Removel in progress。rm 发出去却迟迟删不完，多见于进程仍在写卷或设备忙。等它收尾是默认答案；实在僵死，重启守护进程是最后的手术刀——副作用是同机全部容器重启，生产机慎用。
💡 辨析：stop 超时后的强杀与应用自行退出，在 ps 里都显示 exited，肉眼难辨。区分靠退出码与 inspect：被 SIGKILL 处决的退出码是 137，应用体面退出是 0，业务异常退出则用应用自己的退出码——这个字段在捌部问诊路径里是重要证据。
本节要点回顾
- run 是 create 加 start 的合体词：需要先建不跑的容器时（改配置再启动）才拆开用。
- stop 优雅、kill 强硬、pause 冻结：stop 先 TERM 后 KILL 留了十秒善后窗口，pause 不发信号可恢复。
- rm 有引用检查：running 删不掉；-v 连匿名卷、prune 清 exited 批量尸体。
- RestartCount 在 inspect 里：持续增长是重启风暴的前兆。
- exited 不是 deleted：停下的容器还在，得靠 rm 或 prune 收尾。
状态板上的每个状态都有命令可达，而决定容器"以什么姿势出生"的，是 run 的那几十个义项——3.2 逐组拆解。