应优先用 docker system df -v 和 docker images --format 结合 JSON 输出精准识别可删镜像，避免误删运行中容器依赖或 build cache 引用的镜像，并通过 docker ps -a、inspect 和 buildx du 检查引用关系，再安全批量清理。
用 docker system df 和 docker images 做清理前的准确判断
直接删镜像容易误伤正在运行的容器或未打标签的中间层，得先确认哪些真能删。Golang 脚本里别自己解析 docker images -q 输出再拼接过滤逻辑——那会漏掉 <none></none> 镜像和 dangling 层。正确做法是调用 docker system df -v 获取 JSON 输出（加 --format "{{json .}}" 更稳），再结合 docker images --format "{{.ID}}\t{{.Repository}}:{{.Tag}}\t{{.CreatedSince}}" 补充元数据。
常见错误是只看 REPOSITORY 为 <none></none> 就删，但有些构建缓存层虽然没标签，却被当前 Dockerfile 的后续阶段依赖；还有些镜像被本地 buildx 构建器隐式引用，删了会导致下次构建拉取失败。
- 用
docker images -f "dangling=true" -q只能捕获部分 dangling 镜像，必须配合docker builder prune --dry-run检查 build cache 引用 -
CreatedSince字段在不同 Docker 版本输出格式不一致，建议统一用CreatedBefore过滤（如--filter "before=2024-01-01"） - 脚本启动时加
--prune-system参数才触发docker system prune -f，否则只清理镜像不碰构建缓存和网络
用 exec.Command 安全调用 Docker CLI，别手写 HTTP 请求
有人想绕过 CLI 直连 Docker daemon 的 /images/json API，结果卡在 TLS 验证、socket 路径硬编码、版本兼容上。Golang 标准库的 exec.Command 更可靠：它复用用户环境里的 Docker CLI 配置（包括 DOCKER_HOST、DOCKER_CONTEXT、~/.docker/config.json 认证），且自动处理退出码和 stderr 重定向。
关键点是别忽略 cmd.Run() 的 error 类型——Docker CLI 返回非零码时，exec.ExitError 包含真实退出码，比如 125 是权限不足，126 是命令不可执行，127 是找不到命令。直接用 err.Error() 会丢掉这个信息。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
cmd.CombinedOutput()代替cmd.Output()，避免 stderr 被吞导致调试困难 - 设置
cmd.Timeout（如 30 秒），防止 Docker daemon 卡死拖垮整个脚本 - 对
docker rmi批量操作，每次最多传 50 个 ID，超长参数列表在某些 shell 下会触发Argument list too long
按引用关系递归清理，而不是按时间硬删除
单纯按创建时间删镜像最危险：一个上周构建的 base 镜像可能正被今天跑的容器使用，删了容器就起不来。Golang 脚本得先跑 docker ps --format "{{.Image}}" 拿到所有运行中容器的镜像名，再用 docker image inspect 查它们的 Id 和 RepoDigests，最后比对要删的镜像 ID 是否出现在任一容器的 Image 或 RepoDigests 里。
更隐蔽的是 build cache 引用：docker builder ls 不暴露具体镜像 ID，得用 docker buildx du --verbose 解析 JSON 输出里的 CacheReferences 字段。这部分常被忽略，导致清理后下次 docker build 慢三倍。
- 检查容器状态时用
docker ps -a而非docker ps，避免漏掉已退出但未清理的容器所依赖的镜像 -
RepoDigests是数组，内容形如"registry.example.com/app@sha256:abc123"，需提取sha256:...部分与待删镜像的Id做前缀匹配 - 对 multi-stage 构建生成的中间镜像，
docker images -f "dangling=true"未必能覆盖全，得靠docker system df -v里的Layers字段反向查归属
清理失败时保留上下文，别静默跳过
脚本遇到 docker rmi 失败，不能只打一行 log.Printf("skip %s: %v", id, err) 就完事。得记录完整命令、退出码、stderr 内容、当前镜像的 docker image inspect 输出片段——否则线上出问题根本没法回溯是权限问题、还是被容器锁定、或是 registry 认证失效。
另一个坑是并发清理：Golang 里开 goroutine 调 docker rmi 看似快，但 Docker daemon 本身是单线程处理删除请求，大量并发反而触发排队超时，还可能因竞争导致部分镜像被重复删除报错。
- 失败时把原始
exec.ExitError.Stderr写入临时文件（路径用os.TempDir()+ 时间戳），文件名带镜像 ID 前缀 - 用
sync.WaitGroup控制并发数，上限设为 3～5，比默认的 100 更稳妥 - 对
permission denied类错误，附加检查/var/run/docker.sock的权限和当前用户是否在docker组里
真正难的不是写几行 exec.Command，而是搞清每个镜像背后谁在用、为什么不能删、删了影响什么——这些关系藏在 Docker daemon 的状态里，不在你的 Go 代码里。
