企业官网建设流程全解析

docker ps 这条命令，大概是所有人接触容器技术时敲得最多、也最容易被一带而过的一条。装完环境第一件事是敲它确认服务有没有正常起来，容器跑不起来第一反应还是加个 -a 翻一遍历史。它看起来简单到不需要解释——不就是列个表吗？可真到了线上排查问题的时候，很多人盯着那张只有容器 ID、镜像、状态、端口四列的默认输出，愣是看不出容器到底为什么退出、端口为什么连不上、哪个容器在偷偷吃磁盘空间。这篇内容我把 docker ps 从参数到格式化、从过滤到排错完整拆一遍，顺带聊聊几个只有踩过坑才知道的细节。不管你刚装完环境想确认是否正常，还是已经在维护几十个容器、需要把这条命令接进脚本和监控，下面这些应该都能直接用上。读完你至少能做成两件事：看状态列就能大致判断容器死因，用 format 和 filter 把默认那张表改造成适合自己工作流的形态。

1. 先搞清楚 docker ps 到底在列什么

1.1 一个“查看”命令为什么值得单独拆

很多人对 docker ps 的理解停留在“容器版的 ls”，觉得它没有任何技术含量。这个判断在只有一两个容器的时候成立，一旦容器数量上到两位数、或者容器生命周期短到几秒钟就退出，这条命令的信息密度就会突然变得极其关键。原因在于，容器本身是个黑盒进程，你没有办法像查普通进程那样直接 attach 上去看内部状态，docker ps 输出的那几列，实际上是守护进程从内部数据结构里摘出来的、关于这个容器当前处境的全部公开线索。

我举个具体的例子。一个容器反复重启，你在默认输出里看到的是Restarting (1) 5 seconds ago。这个(1)是退出码，1意味着应用层自己报错退出，而不是被信号杀掉；如果是(137)，那是 128 加 9，说明进程收到了强制终止信号，常见于内存超限被系统干掉。同样一列文字，懂和不懂的人排查方向完全相反。所以这条命令的价值不在于“能看”，而在于“看得懂”，它把容器的创建时间、运行时长、端口绑定、健康检查结果、退出原因全部压缩进几行文本里，你需要的是一套解读方法。

另外一层原因是可编程性。docker ps 支持结构化的过滤和模板输出，意味着它不只是给人看的，还能直接喂给 shell 脚本、监控采集器、告警系统。日常运维里大量重复动作——批量停掉某个镜像的所有容器、找出所有退出码非零的实例、清理超过一定时间的僵尸容器——底层几乎都靠这条命令先筛出目标集合。把它的参数吃透，后面写脚本能省掉一大半的解析逻辑。

1.2 默认输出那几个字段各自意味着什么

敲一次不带任何参数的 docker ps，出来的是七列：容器 ID、镜像、启动命令、创建时间、状态、端口、名称。这七列不是随便排的，从左到右基本遵循“从唯一标识到人类可读描述”的顺序。容器 ID 是十二位短哈希，足够日常区分，但真要拿去写进配置文件或者做精确匹配，建议用--no-trunc拿完整的六十四位，短 ID 在容器数量多的时候存在极小概率的前缀碰撞，虽然概率低，但脚本里因为这种问题排查半天不划算。

镜像列显示的是容器创建时所用的镜像名，注意这里不会告诉你镜像后来有没有被更新过，容器一旦创建，它的镜像引用就固定了，所以看到镜像标签是 latest 也别以为它一定是最新的。启动命令列默认会被截断，长命令后面跟省略号，想看全得加--no-trunc。创建时间列是相对时间，比如“5 minutes ago”，这个相对时间在跨时区协作或者写进日志的时候容易产生歧义，用格式化输出改成绝对时间更稳妥。

状态列信息量最大，它同时包含了运行时长、健康检查结果和退出原因三部分。端口列只在容器做了端口映射时才有内容，格式是“宿主地址:宿主端口->容器端口/协议”，IPv4 和 IPv6 会各占一条，用冒号分隔。名称列是容器名，不指定的话系统会随机生成一个由形容词加人名组成的组合，正式环境建议自己命名，否则批量操作时根本认不出谁是谁。

1.3 命令家族与版本兼容的那点事

早些年这条命令只有docker ps一种写法，后来命令行做了重组，按对象类型归类，于是多出了docker container ls和docker container list两个等价写法。三者执行结果完全一致，底层走的是同一个接口，区别只在于语义清晰度。新写法在脚本里更推荐，因为它明确表达了“我在列容器对象”，可读性更好；而docker ps胜在短，日常手敲更省事。两种写法混用完全没问题，不用纠结统一。

需要留意的是版本差异。老版本里有些选项的行为和新版本不完全一致，比如--format支持的字段在不同大版本之间有过增补，健康检查相关的状态字段是后来才加的。如果你在写跨环境的部署脚本，最好先确认目标环境的版本，用一个最小字段集做兼容，别一上来就用最新字段，否则换台机器就报模板解析错误。我一般的做法是脚本里只依赖容器 ID、名称、状态、镜像这四个最稳定的字段，需要更多信息时再单独查一次。

2. 参数逐项拆解：哪些每天都在用，哪些关键时刻才想起

2.1 控制显示范围：-a、-l、-n、-q 的取舍

默认行为只列正在运行的容器，这一点新手最容易忽略。容器退出了，docker ps里就看不见了，于是很多人第一反应是“我的容器没了”，其实它只是停了，加-a就能看到全部，包括已退出、已创建但没启动的。这个-a是使用频率仅次于默认命令的选项，排查问题的第一步永远是docker ps -a，先确认容器到底是没创建、创建了没起来、还是起来又挂了。

-l是只显示最近创建的那个容器，-n后面跟数字，显示最近创建的若干个。这两个选项在交互式操作里很顺手，比如你刚docker run完一个容器想确认状态，docker ps -l比翻全表快得多。但它们按创建时间排序，不是按启动时间，容器重建之后顺序会变，脚本里依赖这个顺序要小心。

-q只输出容器 ID，是批量操作的标配。配合命令替换可以直接把结果喂给其他命令，比如停掉所有运行中的容器，一行就够。这个选项的输出是纯净的 ID 列表，没有表头没有对齐空格，天然适合管道。我见过有人在脚本里用docker ps加一堆文本处理去提取 ID，其实一个-q就解决了，省下来的解析逻辑全是潜在的 bug 来源。

2.2 看清全量信息：--no-trunc 与 -s 的使用场景

--no-trunc的作用是不截断输出，主要影响三列：容器 ID 变成完整哈希，启动命令完整显示，镜像摘要也完整展示。什么时候必须用？一种是要把容器 ID 写进审计记录或者工单系统，短 ID 不够严谨；另一种是排查启动命令问题时，被截断的那半截命令恰恰是关键，比如一个带了很多参数的 Java 启动脚本，省略号后面可能藏着错误的环境变量。

-s会额外加两列，显示每个容器的可写层大小和虚拟磁盘总大小。这个选项要慎用，因为它需要向守护进程查询每个容器的存储占用，容器数量多的时候会明显变慢，我在几十个容器的环境里试过，加上这个参数响应时间能从几十毫秒涨到一两秒。它的正确用法是定点排查，比如磁盘告警了，用它找出哪个容器的可写层异常膨胀，而不是把它写进日常巡检脚本里天天跑。另外注意可写层大小只统计容器自己写入的数据，挂载的卷不计算在内，所以看到数字很小但磁盘还是满的，要去查卷的占用。

2.3 参数组合时的优先级与相互影响

有几个组合需要提前说清楚，避免用的时候犯迷糊。-q和--format同时出现时，--format优先，因为格式化是更明确的输出意图，-q只是它的一个简化特例。-a和-f status=exited组合时，过滤条件在全集上生效，不用额外再加-a，因为状态过滤本身就隐含了“要看已退出的”，但为了语义清楚，我一般还是会把-a写上。

-l和-n同时出现时以-n为准。--filter多个条件之间的默认关系是“与”，也就是必须同时满足，这点和很多人直觉一致，但涉及名称过滤的正则匹配时容易踩坑，后面过滤那一节会细说。还有个隐性的坑：多个--filter如果用了同一个键、不同值，比如两个status过滤，实际效果是“或”，而不是报错，这个行为在不同版本上表现一致，但文档里写得不显眼，值得记一下。

3. --format 实战：把列表变成自己的运维看板

3.1 模板语法的门槛其实比想象中低

--format用的是 Go 模板语法，听起来吓人，实际常用的就三样东西：字段引用、制表符、换行。字段引用写成点加字段名，比如容器 ID 就是.ID，名称是.Names，状态是.Status。要在同一行拼多个字段，中间用\t分隔，这是制表符的转义写法，能让输出自动对齐成表格。

最常用的写法是在模板前面加table关键字，它会自动补上表头并按列对齐。不加table的话就是纯文本逐行输出，适合喂给脚本。我第一次用的时候不知道有这个关键字，手动用空格对齐了半天，结果字段长度一变全乱，后来发现一个 table 就解决了所有对齐问题。

值得强调的是，模板里可以塞普通文本和符号，比如给每行加个前缀、在字段之间加竖线做视觉分隔、甚至拼出类似 JSON 的结构。这让同一条命令既能输出给人看的报表，也能输出给程序解析的数据，不用再写两套逻辑。

3.2 常用字段清单与拼接技巧

日常用得最多的字段就那么几个，我把它们和默认列做个对应，方便迁移习惯。.ID对应容器 ID，.Image对应镜像，.Command对应启动命令，.CreatedAt对应创建时间，.RunningFor是运行时长，.Ports是端口，.Names是名称，.State是简短状态词，.Status是带细节的完整状态描述。区分.State和.Status很重要，前者只有 running、exited 这种单词，适合做条件判断；后者带时长和退出码，适合给人看。

还有几个不那么常用但很有价值的字段。.Labels输出容器的所有标签，做标签化管理的团队可以用它快速核对；.Mounts列出挂载信息，排查卷映射问题时直接看；.Networks显示容器接入的网络；.LocalVolumes是本地卷数量。健康检查相关的状态在.Status里以括号形式体现，想要单独取出来需要一些字符串处理，模板本身不支持条件分支的复杂逻辑，这时候就退回 shell 去切。

拼接上我常用的一个套路是给输出加统一前缀，比如在每行前面加上时间戳，方便和其他日志合并。模板里直接写死文本没问题，但动态时间戳得靠 shell 变量传进去，命令替换和引号转义要小心，双引号里套单引号、再套反引号是最容易出错的组合，我一般先用 echo 把完整命令打出来确认转义正确，再去执行。

3.3 面向脚本的输出：从人读到机器读

人看的表格和机器解析的格式要分开设计。给人看的时候，列宽对齐、表头清晰、信息密度适中；给脚本用的时候，字段越少越好、分隔符越明确越好、不要表头。我的习惯是维护两个模板，一个用于日常查看，包含名称、状态、端口、镜像四列；另一个用于脚本，只输出 ID 和名称，用冒号分隔，方便后面用 cut 或者 read 拆。

举个实际用法，批量重启某个镜像下的所有容器，先筛出目标再循环操作，整个过程不用碰任何解析 HTML 或者 JSON 的库。这里的关键是让 docker ps 的输出格式固定下来，脚本里只依赖位置，不依赖文本匹配，稳定性会高很多。如果你需要处理容器名里带空格或者特殊字符的情况，记得在 shell 循环里用 while read 而不是 for，for 会按空格拆分，遇到带空格的名称直接崩。

4. --filter 过滤：从一堆容器里精准捞针

4.1 常用过滤键与表达式写法

过滤是这条命令里最被低估的能力。常用的过滤键有七八个：按状态status、按名称name、按镜像ancestor、按标签label、按退出码exited、按端口publish和expose、按网络network、按卷volume、按创建时间先后before和since。写法统一是-f 键=值，等号两边不要加空格，否则会被 shell 当成两个参数。

名称过滤用的是子串匹配，不是精确匹配，也就是说-f name=web会同时命中 web、web-1、my-web-test。想要精确匹配得用正则的锚定写法，加^和$。这一点在批量操作里特别危险，你以为只选中了一个容器，实际选中了一批。我吃过一次亏，清理测试容器的时候用了宽泛的名称匹配，结果把同前缀的生产容器一起停了，从那以后所有涉及写操作的过滤一律加锚定。

按镜像过滤要理解它的语义：匹配的是容器创建时引用的镜像，包括该镜像的所有历史版本关系。用镜像名过滤时，同名不同标签的容器都会被选中；用镜像 ID 过滤则更精确。如果你不确定某个容器到底基于哪个镜像，ancestor配合完整 ID 最保险。

4.2 多条件组合的与或关系

默认多个过滤条件之间是“与”，也就是取交集，这个符合直觉。但有两种情况会打破这个默认。第一种是同一个键给多个值，比如两个status条件，实际是“或”的关系，等于列出状态 A 或者状态 B 的容器。第二种是部分版本对label键的处理，同一个标签键给不同的值，行为可能和预期有出入。稳妥的做法是遇到多值场景先在测试环境验证一下结果集，别直接写进自动化流程。

组合的实用例子：列出所有已退出且退出码非零的容器，用两个条件就行，status=exited加上exited=1之类别。再比如找出某个网络下、某个镜像的所有运行中容器，三个条件叠加，一行命令就能把目标锁定到一个很小的集合，后面接操作命令风险低很多。条件越多，集合越小，出错的代价也越小，这是我写运维脚本时的一条基本原则。

还有个容易忽略的点：过滤是作用在命令看到的全集上的，-a影响的是默认展示范围，但一旦你用了状态过滤，范围会自动扩展到匹配该状态的容器，不需要额外加-a。理解这一点能少写很多冗余参数。

4.3 状态过滤与健康检查的细节

状态过滤常用的值有 running、exited、created、paused、restarting、dead。这里要特别注意 paused 和 restarting 这两个中间态，它们既不是完全活着也不是完全死了，很多监控脚本只判断 running，结果漏掉了卡在 restarting 里的容器。我一般会单独维护一个“异常状态”过滤，把 restarting 和 dead 都拉出来告警。

健康检查的判断不在状态过滤里，它藏在完整状态描述里。一个容器可能是 running 但健康检查结果是 unhealthy，这种情况在默认视图里只有状态列的括号能看出来。做健康巡检的时候不能只看status=running，还得对输出做二次判断，或者用格式化把完整状态取出来后匹配 unhealthy 关键字。这块是我觉得这条命令设计上稍微别扭的地方，希望以后能直接支持健康状态的过滤键。

5. 几个真实场景的排查过程

5.1 容器启动就退出：从状态列读出死因

容器起来几秒钟就退出，是最高频的问题。排查顺序我固定为三步。第一步docker ps -a找到那个容器，重点看状态列的退出码。退出码 0 表示进程正常结束，多半是启动命令跑完就退出了，比如一个前台进程写成了后台执行，或者脚本里缺了保持前台运行的指令。退出码 1 是应用自己报错，得去看日志。退出码 126 和 127 分别是命令不可执行和命令找不到，通常是启动命令写错或者镜像里没有这个可执行文件。

第二步是如果退出码是 137，说明进程收到了强制终止信号，最常见的诱因是内存超过限制被系统终止，也可能是有人手动发了终止命令。这时候去看容器的资源限制配置和宿主机的内存水位，基本能定位。退出码 143 对应的是正常的终止信号，一般是容器被优雅停止，属于正常退出范畴。

第三步才去看日志。很多人一上来就翻日志，其实状态列已经把大方向指明了，先读退出码能省掉大量无效翻找。这个习惯我建议所有人都养成，尤其是在容器数量多、日志量大的环境里。

5.2 端口映射异常：从端口列还原绑定关系

服务连不上，端口问题占很大比例。默认输出的端口列写得很紧凑，格式是宿主地址冒号宿主端口，箭头指向容器端口和协议。看这一列要关注两件事：绑定地址是什么，宿主端口是多少。绑定地址显示为全零地址表示监听所有网卡，显示为回环地址则表示只有本机能访问，外部当然连不上。这个区别在本地开发时经常被忽略，容器里服务正常、本机 curl 也通，换个机器就是不通，原因往往就在这里。

另一个高频问题是宿主端口冲突或者没映射。容器内部的端口是容器自己的，不映射到宿主，外面根本摸不到。想确认某个端口被谁占了，用端口过滤能快速定位到具体容器。如果发现同一个宿主端口出现多条映射记录，说明有容器启动失败或者配置写重复了，这时候要结合状态列看哪个是真的在运行。

5.3 批量清理前的安全确认

清理容器是危险操作，尤其是带数据卷的。我的固定流程是先列后删，绝不直接删。先用过滤把目标集合列出来，加上完整的状态、名称、镜像、创建时间四列，人工扫一遍确认没有误伤，再执行删除。列表这一步省不得，我曾经写过一个自以为很稳的过滤条件，结果因为名称匹配太宽泛选中了不该选的容器，好在先列后删的习惯救了我一次。

对于已经退出的容器，清理前还要确认它挂载的卷有没有数据。容器删了卷默认保留，但如果当初是用自动清理方式启动的，卷会跟着走。这个判断靠容器详情里的挂载信息，光看列表不够，得再查一次。批量操作里我一般会加一个确认环节，把要删的容器数量打印出来，数量超过预期就中止，人眼过一遍再放行。

6. 常见问题与踩坑记录

6.1 问题速查表

6.2 几条不太容易在网上找到的经验

第一条，别把docker ps的调用频率开太高。有些监控方案图省事，每隔一两秒轮询一次，容器数量一多，守护进程的响应压力会上来，极端情况下会拖慢其他操作的响应。轮询间隔我一般设在十秒以上，真要秒级感知状态变化，应该走事件订阅而不是轮询。

第二条，脚本里永远不要依赖默认输出的列顺序和对齐。默认表格是为了人眼优化，字段之间的空格数量会随内容长度变化，用文本切割去解析必然翻车。要解析就用--format固定分隔符，或者干脆用-q只拿 ID。

第三条，涉及写操作的过滤条件，先在末尾加一个--format把目标打印出来跑一遍。这个习惯看起来多一步，实际能挡掉绝大多数误操作。我在好几个环境里把这个动作做成了肌肉记忆，宁可慢十秒，不要让一次误删变成事故。

最后分享一个我自己常用的小组合：一条命令打印出所有容器的名称、完整状态、镜像和创建时间，按创建时间倒序，专治“我记得刚跑过一个什么但不知道叫啥”的健忘症。字段不多，信息够全，扫一眼就能定位。容器多起来之后，这种自己顺手的小命令比任何复杂的监控面板都来得快。