镜像ID默认不唯一，仅显示前12位SHA256；唯一标识是完整digest（需docker images --digests或docker inspect -f '{{.Id}}'获取）；ENV应查inspect中Config.Env字段，而非Dockerfile或容器运行时env。
docker images 命令输出的镜像ID不唯一？
默认 docker images 显示的是镜像的 IMAGE ID，但它只是镜像顶层层的 SHA256 前 12 位，不是完整 digest；多个镜像可能共享同一 IMAGE ID（比如 FROM alpine:3.18 和 FROM alpine:3.19 构建出的空镜像），无法用于精确识别。
- 真正唯一、可复现的标识是镜像的
digest，需用docker images --digests查看（但仅对已带 digest 拉取的镜像有效） - 若要获取完整 ID，得用
docker inspect -f '{{.Id}}' <image-ref>，返回的是sha256:...全长字符串 -
docker images不显示 digest 时，<image-ref>必须是本地存在的、且曾以@sha256:...方式拉取过的镜像，否则字段为空
如何安全提取镜像 ENV 环境变量？
直接读 Dockerfile 的 ENV 行不可靠——构建时可能被后续 ENV、ARG 或 RUN export 覆盖；运行时容器环境还可能被 -e 覆盖。可靠方式是查镜像的配置层：
- 用
docker inspect <image-id>查Config.Env字段，它反映镜像构建完成时的最终 ENV 快照 - 注意：该列表是字符串数组（如
["PATH=/usr/local/sbin", "LANG=C.UTF-8"]），不是键值对，需自己解析=分割 - 某些基础镜像（如
scratch）可能无Config.Env字段，访问前应判空 - 别用
docker run --rm <image> env提取——它启动了容器，受 host / daemon 配置干扰（如/etc/environment注入），且无法反映镜像原始设定
脚本里批量解析镜像 ID 和 ENV 的常见翻车点
写 shell 或 Python 脚本自动处理时，最容易在数据结构和边界上出错：
-
docker images输出是表格格式，列宽不固定，不能用awk '{print $3}'直接取 IMAGE ID——镜像名含斜杠或带 tag 时列会偏移；必须用--format：docker images --format '{{.ID}} {{.Repository}}:{{.Tag}}' - 用
docker inspect -f '{{range .Config.Env}}{{.}} {{end}}'会把所有 ENV 拼成一行无分隔，难以拆分；推荐-f '{{json .Config.Env}}'再交给jq或 Pythonjson.loads() - 镜像 ID 可能是 dangling（
<none>），此时.Repository和.Tag为空，但.ID仍有效——脚本里别假设所有镜像都有名字 - 权限问题：某些私有 registry 镜像，
inspect能查到 ID，但Config字段为空（因 manifest 不含 config blob），此时.Config.Env会报错或为 null
为什么 docker image ls --format 和 inspect 结果有时不一致？
因为 docker images 显示的是本地镜像索引视图，而 docker inspect 读的是具体镜像 JSON 配置；两者来源不同，更新时机也不同：
- 执行
docker pull后，images列表立即更新，但旧镜像的配置文件仍留在磁盘，inspect查的还是原内容 - 如果用
docker build --cache-from复用中间层，新镜像 ID 可能指向旧层，导致inspect返回的Created时间早于images显示的CREATED -
--format中的{{.ID}}是短 ID，inspect中的{{.Id}}是长 ID，大小写也不一样（前者小写，后者首字母大写），混用会导致匹配失败 - 最稳的做法：所有自动化流程统一用长 ID（
sha256:...）作为主键，从inspect获取，再反查images --format做映射
Config.Env 这两个锚点，其他都是围绕它们做校验和适配。 
