直接看镜像分层结构就能定位体积膨胀元凶：Docker镜像由多个只读层叠加而成，每层数据永久保留，即使后续用rm删除文件，原始数据仍占空间；通过docker history查看各层大小，重点关注异常大层（如RUN apt-get install、COPY . .、wget解压等），再用dive工具逐层分析文件分布，并检查.dockerignore和基础镜像合理性。
直接看镜像分层结构，就能定位体积膨胀的元凶。Docker 镜像不是整体文件，而是由多个只读层叠加而成，每一层都永久保留写入的数据——哪怕后续层用 rm 删除了文件，原始数据仍在底层占着空间。
用 docker history 查看各层大小
运行命令：
docker history <image-name>输出中会显示每条指令对应的一层，以及该层的大小（SIZE 列）。重点关注那些异常大的层，比如：
- 某次
RUN apt-get install后突然多出 150MB -
COPY . .指令引入了整个项目目录，包括.git、node_modules或测试数据 -
RUN wget && unzip下载解压大文件，即使后面删了，体积仍计入
用 dive 工具深入查看文件分布
dive 是专为镜像分析设计的交互式工具，能逐层展开并统计每个路径占用的空间：
- 安装后运行 dive <image-name>
- 按
Tab切换到“Layers”视图，观察哪一层新增了大量文件 - 切换到“Image”视图，直接看到哪些目录（如
/usr/lib/python3.9、/root/.cache）占用了最多空间 - 特别注意
/tmp、/var/cache、.git、__pycache__等高频冗余路径
检查 .dockerignore 是否生效
如果构建时 COPY 了整个项目，但没忽略无关文件，就会把开发期产物一起打进镜像。确认 .dockerignore 包含：
-
.git、.gitignore -
node_modules（前端）或venv、__pycache__（Python） -
*.log、logs/、tests/、docs/ -
Dockerfile、.dockerignore自身（避免循环嵌套）
验证基础镜像是否合理
基础镜像本身可能就占几十甚至几百 MB。用 docker history 第一行看 base 镜像来源：
- 若显示
ubuntu:22.04（约 70MB）或debian:slim（约 25MB），可考虑换成alpine:latest（5MB） - 若应用是 Go/Java/Python 静态编译产物，优先试
gcr.io/distroless/base-debian11（15MB）或scratch（0MB） - 避免使用
ubuntu:latest这类浮动标签，会导致缓存失效和不可复现构建
