必须用 docker history --no-trunc 结合 --format 提取 ISO8601 时间戳并计算层间差值，才能精准定位耗时最长镜像层；默认相对时间不可比，截断指令会误判构建逻辑，BuildKit 空层需跳过。
要精准定位镜像中哪一层构建耗时最长、哪条指令拖慢了 CI 流程，必须查看每层的完整构建历史并提取时间维度信息——docker history 默认不显示构建耗时，需结合 --no-trunc 与自定义格式解析 CREATED 字段，再辅以外部排序或脚本计算差值。
查看基础构建历史并识别时间字段
执行 docker history nginx:alpine 查看默认输出，注意 CREATED 列显示的是“2 weeks ago”这类相对时间，无法直接比对耗时；该列实际对应每层生成的绝对时间戳，但被格式化隐藏了精确到秒的信息。
这一步操作起来很简单，直接把镜像名填进去就行。
若未加 --no-trunc，CreatedBy 字段可能被截断为 `/bin/sh -c #(nop) RUN apt-get update &&...`，导致无法确认是否真执行了清理动作——【缺少 --no-trunc 会导致关键指令不可见，误判构建逻辑】。
用 --no-trunc 显式展开完整时间与指令
运行 docker history --no-trunc nginx:alpine，此时 CREATED 列仍为相对时间，但 CREATED BY 字段会展开成完整 shell 命令，例如：/bin/sh -c #(nop) COPY file:abc123 in /app/。
只有展开后，才能匹配 Dockerfile 中的真实行号，进而反推哪一行在 CI 日志里耗时异常。
注意：官方镜像（如 ubuntu:22.04）启用 BuildKit 构建后，部分中间层 CREATED BY 会显示为
提取绝对时间戳并计算层间耗时差
第一步：导出带 ISO8601 时间格式的完整历史记录
执行 docker history --no-trunc --format '{{.ID}}|{{.Created}}|{{.Size}}|{{.CreatedBy}}' nginx:alpine > history.tsv，该命令将每层的 Created 字段输出为类似 2025-03-17T09:22:41.324123887Z 的完整时间戳。
第二步：用 awk 或 Python 按时间戳倒序排列，并逐行计算与上一层的时间差
例如 Linux 下快速估算（假设 tsv 文件已按构建顺序从底到顶排列）：
awk -F'|' 'NR==1{prev=$2; print $0 " | (base)"; next} {cmd="date -d \"" $2 "\" +%s 2>/dev/null"; cmd | getline now; close(cmd); if(now!=prev && prev!=0) diff=now-prev; else diff=0; print $0 " | +" diff "s"; prev=now}' history.tsv | column -t -s '|'
输出中最后一列即为该层相对于下一层的构建耗时秒数，最大正值往往对应 RUN 编译或下载操作。
跳过手动计算：用 --format 直接聚焦高耗时嫌疑层
方法一：只看大于 30MB 且含 RUN 的层（通常耗时集中）
docker history --no-trunc nginx:alpine | awk '$3 ~ /MB/ && $3+0 > 30 && $4 ~ /RUN/ {print}'
方法二：过滤出创建时间早于 2025-01-01 的层（老旧缓存层常拖慢构建）
docker history --no-trunc --format '{{.ID}} {{.Created}} {{.Size}} {{.CreatedBy}}' nginx:alpine | grep '2024-' | head -3
这两类层大概率是构建瓶颈所在，无需全量计算即可快速锁定目标。
