VSCode Docker扩展显示镜像大小不准，因依赖docker images --format且列宽受限，悬空镜像、多架构镜像、单位省略等导致误判；准确查看需用docker history、docker system df -v或docker image inspect获取真实字节数与共享层信息。
Docker 扩展自带的镜像列表就显示大小，不需要额外工具或插件。 它直接调用 docker images 输出，但默认列宽有限，小尺寸（如几十 MB）可能被截断或显示为 “—”，容易误判实际占用。
为什么镜像大小在 VSCode 里看起来不准或不全？
VSCode 的 Docker 扩展（Microsoft 官方版）使用 docker images --format 获取数据，底层依赖 CLI 的字段映射。常见问题包括：
- 镜像标签为
<none></none>（悬空镜像）时，SIZE字段有时显示为空或 “—”，但实际可能很大（比如中间构建层） - 多架构镜像（如
linux/amd64和linux/arm64同名 tag）在本地只存一份架构，但扩展不显示架构信息，容易误以为重复拉取 - 列宽固定，超过 6–7 个字符的大小（如
1.24GB）会被省略为1.24G…，丢失单位精度
怎么准确查看某个镜像的真实大小和组成？
右键镜像 → Inspect Image，会打开一个 JSON 面板，里面 Size 字段是准确字节数；更实用的是终端里手动查：
- 看总大小和分层：运行
docker history <image-name></image-name>，注意SIZE列——它反映每层增量，不是累计值 - 看真实磁盘占用（含共享层）：用
docker system df -v，重点关注Reclaimable和各镜像的Shared Size - 查某镜像所有层 ID 和大小：运行
docker image inspect --format='{{.Id}} {{.Size}}' <image-name></image-name>，输出是十六进制 ID 加字节数
哪些操作会让镜像大小显示异常？
不是 UI bug，而是 Docker 自身机制导致的显示偏差：
- 执行
docker build --no-cache后，新镜像可能和旧镜像共用基础层，但docker images仍给每镜像独立标“大小”，VSCode 照搬这个值，容易高估总空间占用 - 用
buildx构建多平台镜像后推送到本地 registry（如localhost:5000），这些镜像不会出现在 Docker 扩展的 Images 列表里——因为扩展默认只读docker images本地仓库，不查 registry - WSL2 + Docker Desktop 组合下，如果 VSCode 在 Windows 侧启动，而
dockerCLI 实际指向 WSL2 中的 daemon，docker images可能返回空或旧缓存，导致扩展显示大小为 “—”
真正影响清理决策的不是单个镜像标称大小，而是 docker system df 里的 RECLAIMABLE 值。VSCode 的数字只适合快速比对，别直接拿它算磁盘还剩多少空间。
