定期用 docker prune 清理悬挂镜像、孤儿卷等构建垃圾，需按容器→悬挂镜像→未引用镜像→孤儿卷→构建缓存顺序执行，避免误删；推荐 cron 定时运行分步命令组合并加绝对路径与错误屏蔽。
在 Linux 上用 docker prune 定期清理构建垃圾镜像和孤儿卷，核心是分清“谁该删、谁不能动”，再套进定时任务自动执行。不盲目加 -a 或 --volumes，就能兼顾安全与效果。
先搞懂哪些资源真算“垃圾”
构建过程留下的典型垃圾有两类：
-
悬挂镜像（dangling images）：build 时没打标签、或重打标签后旧层变成
<none>: <none></none></none>，无名无主，占空间又没用； -
孤儿卷（dangling volumes）：容器删了但卷没删，或者创建后从没挂载过，
docker volume ls里显示为<none></none>，数据已无关联容器。
注意：带名字的镜像即使没运行，只要某个已停止容器还引用它，就不是“垃圾”；命名卷哪怕没挂载，只要被某个容器声明过（哪怕已退出），prune 也不会动它。
推荐的分步清理命令组合
比直接上 docker system prune -a --volumes -f 更可控，也更符合日常开发/CI 场景：
- 删所有已停止容器：
docker container prune -f（释放镜像依赖，为下一步铺路）； - 删所有悬挂镜像：
docker image prune -f（安全，不影响带名镜像）； - 删所有未被任何容器（含已停止）引用的镜像：
docker image prune -a -f（建议放在容器 prune 之后执行）； - 删所有孤儿卷：
docker volume prune -f（确认无残留容器后再运行）； - 顺手清构建缓存：
docker builder prune -f（BuildKit 缓存常占 GB 级空间）。
写成一行脚本放进 cron 定时执行
例如每天凌晨 2 点自动清理，把下面这行加进 crontab -e：
说明：
- 用绝对路径调用
docker，避免 cron 环境变量缺失导致失败； - 每条命令用
&&连接，前一条失败则后续不执行，降低误删风险； -
2>/dev/null屏蔽标准错误输出，保持日志干净（如需调试可去掉）； - 首次运行前建议手动跑一遍，观察输出是否符合预期。
加点防护，避免误删关键资源
自动化虽方便，但得防住几个常见坑：
- 不要在生产环境服务器上启用
docker system prune -a --volumes -f，它会一并删自定义网络，可能中断服务； - 如果用了命名卷存数据库数据（如 PostgreSQL 的
pgdata卷），确保这些卷始终被某个容器显式挂载，否则volume prune会当孤儿处理； - CI 构建机若依赖本地镜像缓存提速，可跳过
image prune -a，只保留prune -f清悬挂镜像 +builder prune -f清构建层。
