docker history 命令可查看镜像每层的指令、大小、创建时间，定位异常大层（如几百mb）及其对应 run 指令；结合 docker image inspect 查 size 和 rootfs.layers，再用 docker system df -v 交叉验证真实层大小，精准识别缓存、日志等隐藏膨胀源。

镜像体积过大，往往不是表面看到的文件多，而是大量隐藏的临时文件、缓存、日志或未清理的构建中间层在悄悄“吃掉”空间。排查和清理的关键在于分层定位、精准识别、安全删除。

查清镜像实际构成：用 docker image inspect 和 history

先确认镜像体积来源是否真在镜像层内：

• docker image inspect ：查看镜像元数据，重点关注 Size 和 RootFS.Layers 列表，确认总大小和各层哈希
• docker history ：显示每一层的命令、大小、创建时间。重点看哪些层异常大（比如几百MB），对应的是哪条 RUN 指令——这往往是临时文件藏身之处（如 RUN apt update && apt install -y ... && rm -rf /var/lib/apt/lists/* 若漏掉清理，就会把整个包缓存固化进镜像）

定位容器运行时产生的隐藏临时文件

有些文件不在镜像里，但在容器启动后动态生成（比如应用日志、tmp 目录写入、/dev/shm 或 /run 中的运行时数据），尤其当容器反复重启却未清理时：

• 进入正在运行的容器：docker exec -it sh
• 快速扫描大目录：du -sh /tmp /var/tmp /dev/shm /run | sort -hr
• 查找大于100MB的普通文件：find / -type f -size +100M 2>/dev/null | xargs ls -lh
• 特别注意：/var/log/journal（若启用 journald）、/root/.cache、/app/node_modules（前端项目未 .dockerignore）、/usr/src（编译残留）等高频藏污纳垢点

清理构建阶段残留与无效镜像资源

真正释放空间，不能只删镜像，要连带清理构建缓存、悬空层、未使用卷：

• docker system df：看清实际占用——Images、Containers、Local Volumes、Build Cache 各占多少
• docker builder prune：清除构建缓存（尤其是 BuildKit 缓存，可能达数GB）
• docker image prune -a：删除所有未被容器引用的镜像（加 -f 跳过确认）
• docker system prune -a --volumes：彻底清理（含 volumes），生产环境慎用，建议先 docker volume ls 确认无重要数据

预防下次再膨胀：从 Dockerfile 就控制临时文件

治本之策是让临时文件不进镜像：

• 合并 RUN 指令，避免分层残留：RUN apt update && apt install -y curl && rm -rf /var/lib/apt/lists/*
• 使用多阶段构建（multi-stage）：编译环境用完整镜像，最终只 COPY 二进制或静态资源到精简基础镜像
• 添加 .dockerignore 文件，排除 node_modules、.git、logs/、*.log、tmp/ 等目录
• 对日志类输出，重定向到 /dev/stdout 而非本地文件；或挂载外部卷管理日志生命周期