最轻量可靠的清理方案是crontab+自定义shell脚本：先用docker images -f "dangling=true"识别repository和tag均为且无引用的镜像，再以docker image prune -f --filter "dangling=true"安全清理，配合加锁、日志与每6小时定时任务执行。
直接用 crontab + 自定义 Shell 脚本 定期清理 Docker 悬挂镜像（dangling images），是最轻量、可靠且无需额外依赖的方案。关键不是“扫描后门”，而是消除攻击者可能利用的残留镜像执行面——悬挂镜像本身不运行，但若含恶意构建层或被误挂载进容器，可能成为隐蔽入口。
识别真正的悬挂镜像（避免误删）
Docker 的 dangling=true 镜像特指：没有仓库名（REPOSITORY 为 <none></none>）且没有标签（TAG 为 <none></none>），同时未被任何容器或构建缓存引用。这类镜像无法通过镜像 ID 正常拉取或复用，长期滞留仅增加磁盘占用与潜在风险。
- 手动确认命令：
docker images -f "dangling=true" --format "{{.ID}}\t{{.Repository}}\t{{.Tag}}\t{{.Size}}" - 注意：不要混淆
docker system prune -f——它会同时删掉停止容器、网络、构建缓存，可能影响开发/CI 流程 - 真正安全的清理目标只有
docker image prune -f -f（两个-f：第一个强制、第二个跳过确认；等价于docker image prune -f --filter "dangling=true"）
编写最小化清理脚本（带日志与防重入）
保存为 /usr/local/bin/clean-dangling-images.sh，赋予可执行权限（chmod +x）：
- 开头加锁：
if [ -f /tmp/.clean-dangling-lock ]; then exit 0; fi; touch /tmp/.clean-dangling-lock - 执行清理：
docker image prune -f --filter "dangling=true" 2>&1 | tee -a /var/log/docker-dangling-clean.log - 记录时间戳：
echo "$(date '+%Y-%m-%d %H:%M:%S') - Cleaned $(grep 'Total reclaimed' /var/log/docker-dangling-clean.log | awk '{print $4}') space" >> /var/log/docker-dangling-clean.log - 结尾解锁：
rm -f /tmp/.clean-dangling-lock
配置定时任务（推荐每6小时一次）
运行 sudo crontab -e，添加：
0 */6 * * * /usr/local/bin/clean-dangling-images.sh
- 不用 root 用户 crontab？确保执行用户有
docker组权限（usermod -aG docker $USER） - 日志路径需提前创建：
sudo mkdir -p /var/log && sudo touch /var/log/docker-dangling-clean.log && sudo chown root:root /var/log/docker-dangling-clean.log - 测试脚本是否生效：
sudo /usr/local/bin/clean-dangling-images.sh && tail -5 /var/log/docker-dangling-clean.log
增强防护：配合镜像签名与构建约束（非定时但关键）
单纯删悬挂镜像治标，还需从源头减少生成：
- CI/CD 构建时加
--squash（Docker 23.0+ 已弃用，改用 BuildKit 的docker build --no-cache --progress=plain .配合DOCKER_BUILDKIT=1） - 启用 Docker Content Trust（
export DOCKER_CONTENT_TRUST=1），只拉取已签名镜像，阻断恶意基础镜像注入 - 在
/etc/docker/daemon.json中配置"live-restore": true和"default-ulimits"，降低异常镜像逃逸影响
