直接看镜像构建历史是理解应用依赖最务实的路径，通过docker history可逐层还原from、run、copy等指令，识别基础镜像、软件依赖（如apt-get install curl）、运行时配置及缺失层线索，再结合docker inspect确认环境变量、启动命令等运行时依赖。
直接看镜像构建历史，是理解应用依赖最务实的路径。它不靠猜，也不依赖别人给的文档，而是从镜像本身一层层“剥洋葱”，把 FROM、RUN、COPY 这些指令还原出来，自然就显现出依赖链条。
从 docker history 看出基础镜像和运行环境
执行 docker history 镜像名:标签，第一行（最底层）通常就是基础镜像，比如 ubuntu:22.04 或 alpine:3.18。这一层决定了整个应用运行的操作系统和初始工具集。如果看到 FROM golang:1.21 AS builder，说明该镜像用了多阶段构建，但最终运行阶段的基础镜像还得往下找——历史列表里最上面那个非 <missing></missing> 的 FROM 指令才是实际运行时依赖的底座。
识别中间层里的软件依赖
中间几层往往对应关键依赖安装动作。例如：
-
/bin/sh -c apt-get update && apt-get install -y curl jq→ 表明应用依赖curl和jq -
/bin/sh -c pip install -r requirements.txt→ 说明 Python 依赖来自requirements.txt，可进一步用docker run --rm 镜像名 cat /app/requirements.txt查看具体内容 -
/bin/sh -c npm ci --only=production→ 暗示 Node.js 生产依赖已固化，且未包含开发依赖
注意那些没清理缓存的层，比如只执行了 apt-get install 却没跟 && apt-get clean，这类层体积大、风险高，也属于隐性依赖残留。
结合 docker inspect 确认运行时依赖项
history 告诉你“装了什么”，inspect 则帮你确认“用的是什么”。运行：
docker inspect 镜像名:标签 | grep -A 5 'Config.*Env\|Cmd\|Entrypoint'
重点关注：
-
Config.Env：环境变量可能指向数据库地址、API 密钥来源，间接反映外部服务依赖 -
Config.Cmd或Config.Entrypoint：启动命令是否调用 Java、Python、Node 等解释器？是否加载特定配置文件（如--config /etc/app/conf.yaml）？这些都属于运行时强依赖
留意缺失信息与安全线索
如果某一层的 CREATED BY 显示 <missing></missing>，常见于以下情况：
- 该层由
docker build --squash合并生成（原始指令不可见） - 镜像来自私有构建流程，中间步骤被隐藏
- 使用了 BuildKit 的高级特性（如 secret 挂载），部分 RUN 指令不记录完整命令
这时建议加 --no-trunc 参数重试，并配合 docker image inspect --format='{{json .RootFS.Layers}}' 查看实际层摘要，再逐层比对是否缺失预期的安装步骤——缺失本身，就是一种依赖线索。
