需结合状态、时间、命名和用途综合判断：重点筛查exited/created状态容器，按运行时长倒序排列识别长期闲置者，检查容器名（如tmp/test/dev）、镜像标签及挂载目录，再通过docker inspect和docker logs确认是否可安全删除。
docker ps -a 本身只列出所有容器（包括已停止的），但不能直接“筛查”或自动识别“历史残留”。要精准定位真正需要清理的残留容器，得结合状态、创建时间、命名特征和使用意图来判断。
看状态：重点盯住 Exited 和 Created 状态
运行中的容器（Up）通常不是残留；真正该关注的是：
- Exited：已退出但未删除，最常见残留类型。比如调试时 run 了一次就忘了 rm
- Created：容器已创建但从未启动过，常因 docker run 参数错误或中断导致
- Dead / Removing（卡住状态）：极少数情况，可能需 force 清理
按时间排序：快速定位长期闲置容器
用 docker ps -a --format "table {{.ID}}\t{{.Status}}\t{{.RunningFor}}\t{{.Names}}" --sort runningfor，可按运行时长倒序排列。刚退出的排在最后，停运数天/数周的排最前——这些大概率是残留。
也可加 --filter until="2024-05-01"（替换为你关心的时间点）筛选指定时间前创建的容器。
查名字和标签：识别临时/调试容器
很多残留容器名带明显临时特征：
- 默认随机名（如 romantic_meninsky、eloquent_fermat）——没重命名的基本可判为一次性用途
- 含 tmp、test、dev、debug、backup 等关键词
- 镜像名含 :latest 或无 tag，且没绑定业务服务名
确认是否真可删：避免误伤
别急着批量删。先对可疑容器执行：
-
docker inspect 查
Mounts和HostConfig.Binds，确认没挂载重要宿主机目录（如数据库数据卷、配置文件） - docker logs 看退出原因，若含 exit code 0 且无报错，大概率是正常结束的一次性任务
- 检查
NetworkSettings.Networks是否连了自定义网络——如果连了且其他容器还依赖它，删前需评估影响
