命令是干什么的
docker history 按层列出镜像的构建记录，加上 --human=false 后每层显示精确字节数。它是镜像瘦身的第一步：先确认体积大头落在哪一层，再决定是换基础镜像、合并 RUN 还是清理缓存。要记住层大小是差量，删除类操作会产生负值层，单看某一层很小并不代表最终镜像就小。
基本信息
| 用途 | 按层分析镜像体积，定位主要贡献层 |
|---|---|
| 语法 | docker history [--no-trunc] [--human=false] --format ... 镜像 |
| 配套命令 | docker image inspect --format '{{.Size}}' 镜像 |
| 关键语义 | 层大小是差量，可能存在负值（净删除） |
| 前提 | 镜像需已在本地，远程镜像先 pull |
典型使用场景
- 版本发布前体检，确认镜像体积没有异常增长
- 瘦身前后对比，验证优化是否真正落到镜像上
- 定位「哪一步装了大包」，据此决定是否改多阶段构建
- 排查 CI 缓存失效后的体积回归
- 与容器内目录占用对照，确认体积来源
定位体积大头
定位体积大头
docker history --no-trunc --human=false --format '{{.Size}} {{.CreatedBy}}' app/web:1.0 | sort -hr | head -10
docker image inspect app/web:1.0 --format '{{.Size}} bytes' # 镜像总大小
docker history app/web:1.0 # 人类可读概览
docker image ls --filter reference=app/web --format '{{.Size}} {{.Tag}}' # 版本间对比输出逐列读法
| 列 | 含义 | 读法 |
|---|---|---|
| IMAGE | 层 ID | 悬空层显示为 <missing> |
| CREATED BY | 该层的构建指令 | 指令过长时需 --no-trunc 才完整 |
| SIZE | 该层的净字节变化 | 负值表示这一步以删除为主 |
| 总大小 | inspect 的 .Size | 与压缩后拉取体积不是同一口径 |
history 里出现 <missing> 层是常见现象，多来自多阶段构建的中间阶段或已被清理的层，它们不占本地空间，但会影响按层累加的直觉判断。
临时文件必须写在同一条 RUN 里创建并删除：apt/yum 缓存、编译中间产物跨层删除只是记录删除动作，原始数据仍留在镜像里。
瘦身排查顺序
- 先看镜像总大小，确认是否真的需要瘦身，再按层排序找大头
- 大头落在基础镜像层时，考虑换更小的基础镜像或改成多阶段构建
- 大头出现在同一条 RUN 内时，检查安装与清理是否被拆成了两条指令
- 与容器内目录占用对照，判断体积来自依赖、数据还是构建产物