用 docker history 和 dive 配合可准确定位镜像臃肿层及原因：history 快速识别大体积层、未清理缓存层和碎片化 RUN 层；dive 交互式分析各层文件增删与大小分布，聚焦基础镜像过大、包缓存残留、构建产物混入和 .dockerignore 缺失四类问题。
直接用
dockerhistory
和
dive
两个工具配合看，就能准确定位臃肿在哪一层、由什么文件导致。
用 docker history 快速定位可疑层
这是最轻量的起点。运行：
docker history <镜像名>
它会列出所有镜像层，含大小、创建命令和时间。重点关注：
体积异常大的单一层（比如超过100MB）
带有
、
、
等构建动作但没清理缓存的层
多条连续的小层（说明 RUN 指令拆得太碎，本可合并）
用 dive 深度查看每层文件构成
dive
是专为分析镜像层设计的交互式工具，能直观看到“哪一层加了什么、删了什么、占了多少空间”。
Docker Sandbox
创建并管理 Docker 沙箱虚拟机环境以安全执行代理。适用于运行不受信任代码、探索包或隔离代理工作负载。支持 Claude、Codex、Copilot、Gemini 和 Kiro 代理，并提供网络代理控制。
下载
安装后运行：
dive <镜像名>
进入界面后：
左侧选中某一层，右侧实时显示该层新增/修改/删除的全部文件
按大小排序文件，一眼揪出大文件（如未清理的
、整个
、调试符号
文件）
底部显示“Layer Efficiency”评分，低于80%通常意味着该层存在明显冗余
重点检查四类典型臃肿来源
结合 history 和 dive，盯住以下高频问题点：
基础镜像本身过大
：比如用了
（70MB+）而非
（5MB）或
包管理器缓存未清理
：Debian/Ubuntu 镜像中
常占 30–60MB；Alpine 中
未加
也会残留
构建产物混入运行镜像
：Go/Rust 编译器、Python 的
、C++ 的
目录被 COPY 进最终镜像
忽略 .dockerignore
：源码中
、
、
被意外打包进镜像，单个
就可能超200MB
验证修复效果的简单方法
改完 Dockerfile 后，别急着推送到仓库。本地快速验证：
重新构建：
docker build -t test-img .
对比体积：
docker images | grep test-img
再跑一次
dive test-img
，确认大文件是否消失、效率分是否提升
apt installnpm installgo build/var/lib/apt/lists/node_modules.debugubuntu:22.04alpine:3.20python:3.11-slim/var/lib/apt/lists//var/cache/apk/--no-cache.pycbuild/node_modules.gitlogs/node_modules