Docker镜像在磁盘上以分层只读方式存储于/var/lib/docker/overlay2/，每层对应唯一ID子目录；容器运行时叠加可写层，共享只读层但独占可写层；Dockerfile每条指令生成一层，内容哈希相同则复用同一物理层。
理解Docker镜像在磁盘上的物理存储，关键在于抓住“分层”和“只读叠加”这两个核心。镜像不是一整块打包的文件，而是一组按顺序堆叠的、彼此独立的只读文件系统层（Layer），底层由UnionFS（如overlay2）驱动实现。
镜像层对应磁盘上的真实目录
Docker默认使用overlay2存储驱动，所有镜像层都实际存放在/var/lib/docker/overlay2/目录下。每层都有唯一ID（如abc123...-diff），对应一个独立子目录，里面是该层新增或修改的文件内容。基础镜像层（如alpine:3.15）的层目录会被多个镜像共享，不会重复存储。
- 执行
docker inspect <image-id></image-id>，查看GraphDriver.Data.MergedDir和Layers字段，就能看到各层对应的物理路径 -
docker history <image-name></image-name>显示的每一行，基本对应一个/var/lib/docker/overlay2/<layer-id>/diff</layer-id>目录 - 相同父层的镜像（比如ubuntu:20.04和基于它的nginx镜像）共用底层目录，节省空间
只读层 + 可写层 = 容器运行时视图
镜像本身全是只读层；容器启动时，Docker会在镜像最上层再挂载一个**可写层**（也叫容器层），所有文件创建、修改、删除操作都发生在这里，不影响底层镜像。
- 这个可写层同样位于
/var/lib/docker/overlay2/中，但属于容器生命周期，停止后若未用volume保存，数据即丢失 - 你往容器里touch一个文件，它不会出现在镜像层中，只存在于该容器专属的可写层目录里
- 因此，两个基于同一镜像启动的容器，并不共享磁盘空间——它们各自有独立的可写层，但共用全部只读层
构建过程直接映射为层的追加
Dockerfile每条指令（除FROM外）都会生成一层，且只有内容变化才会触发新层生成。这直接影响磁盘写入行为：
-
RUN apt update && apt install nginx→ 生成一层，包含安装后的二进制、配置等变更 - 如果把
COPY app.py /app/和RUN pip install -r req.txt拆成两行，就产生两层；合并为一行则只生成一层 - 层越少，镜像体积越紧凑，拉取和启动也更快；但调试时多层更利于利用构建缓存
共享与复用是分层设计的物理体现
本地所有镜像的只读层，只要内容一致（哈希值相同），就指向同一个磁盘目录。例如：
- 你pull了
redis:7.0和redis:7.0-alpine，若它们共用某个基础层（如alpine:3.18的某层），该层在磁盘上仅存一份 - 你用
docker commit从容器创建新镜像，Docker不会拷贝整个容器文件系统，而是把当前可写层打包为一个新只读层，叠加在原镜像层之上 -
docker system df -v能清晰看到镜像层（Images）、容器层（Containers）、本地卷（Volumes）各自的磁盘占用和复用情况
