docker ps 按 name=foo 过滤时也选中了 foobar

运行 docker ps --filter name=foo，列表里却同时出现 foo 和 foobar。如果脚本直接把这些 ID 交给停止或删除命令，就可能操作到另一个服务。

Docker 的 name 过滤器允许匹配容器名称的一部分。name=foo 中的等号分隔过滤键和值，不表示“名称必须等于 foo”。下面针对 Docker CLI 的容器查询；Compose 服务名、Swarm 服务名和容器内部 hostname 是不同标识。

先看完整名称，不要只看 ID

在原来使用的 Docker 连接参数下查看：

docker container ls --all --filter 'name=foo' \
  --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'

foo 是示例名称。--all 包含已退出的容器；没有它时，默认列表只显示运行中的容器。因此，“列表没有输出”还不能单独证明容器不存在。

这里保留名称和状态，方便识别 foo、foobar 等不同对象。--quiet 只减少输出字段，不会改变过滤范围，更不会让部分匹配变成精确匹配。

如果原命令指定了远程主机或 Docker context，查询时必须沿用同一连接方式。不同 daemon 上的同名容器是不同对象，不应拿本地查询结果解释远程脚本的行为。

已知名称时直接检查容器

要取得名为 foo 的容器状态，可以直接使用容器检查入口：

docker container inspect --format \
  '{{.Id}} {{.Name}} {{.State.Status}} {{.Config.Image}}' foo

这会返回对应对象的完整 ID、名称、状态和镜像配置名，不需要先做名称子串搜索。使用 docker container inspect 也把对象类型限定为容器，避免通用检查入口同时考虑其他同名 Docker 对象。

核对返回名称是否确实是目标。Docker 检查结果中的名称通常带前导 /，例如 /foo；不要因此误认成另一个名称。镜像配置名用于辅助辨认，镜像标签本身不等于不可变的镜像内容证明。

只想在脚本中确认检查是否成功，可以使用 shell 条件语句：

if docker container inspect --format '{{.Id}} {{.Name}} {{.State.Status}}' foo; then
  printf '%s\n' '已取得容器信息，请核对名称与状态'
else
  printf '%s\n' '检查失败，请保留并查看上面的 Docker 错误' >&2
fi

不要把失败分支直接写成“容器不存在”，更不要在其中立即创建同名容器。daemon 不可达、权限不足和参数错误也会导致失败。先区分明确的找不到对象错误与连接问题，避免网络故障触发错误的重建流程。

存在、正在运行和可提供服务要分别判断

成功取得容器信息，只说明这一刻对象可被检查。容器可能处于 exited、created 或其他状态；需要运行中的实例时，应明确读取状态。即便状态是 running，应用也可能尚未就绪或正在报错，应继续使用服务自己的健康检查。

容器检查入口也接受 ID。脚本若把用户输入直接当作名称，仍要核对返回的名称与预期值，避免把看起来像 ID 的输入解释成另一个对象。不要只依赖“命令返回成功”。

查询与后续动作之间，容器还可能被其他部署流程替换。需要操作同一个已核对实例时，保存该次返回的完整 ID，并在既有运维流程里确认其身份和状态；不能把之前检查过的名称当成永远指向同一实例的保证。

验收脚本是否仍会选中相似名称

在隔离测试环境中，用已经准备好的 foo、foobar 等测试容器核对查询：部分名称过滤可以返回多项，直接检查目标名称应只返回对应对象。再检查已退出目标、名称不存在和 daemon 连接失败时，脚本是否走入各自的处理分支。

本次修正应先停留在只读查询。确认目标选择逻辑后，再接回原有操作步骤；不要用批量停止或删除来验证是否选对。保留脚本原版本便于回退，但若旧版本已经选错范围，回退时应同时禁用自动动作，不能恢复误操作路径继续运行。