docker镜像分层由存储驱动具体实现，如overlay2通过lowerdir/upperdir/mergedir联合挂载，各层为只读快照目录，写操作重定向至可写层，保障镜像不可变性。
docker 镜像的分层不是抽象概念，而是由底层存储驱动具体实现的物理结构。分层机制依赖存储驱动提供的联合挂载能力，没有合适的驱动，镜像就无法按预期叠加、复用和运行。
分层结构如何被存储驱动落地
镜像每一层本质上是文件系统的一个快照目录，但这些目录不能直接拼在一起使用——必须靠存储驱动把它们“联合”成一个可访问的整体。比如：
-
overlay2（当前默认）：将各只读层设为
lowerdir，容器运行时新增的修改放在upperdir，最终通过mergedir向容器暴露统一视图； -
aufs：类似逻辑，但用
branched layers表达层级顺序，对并发写入支持较弱； - btrfs：利用文件系统原生的 CoW（写时复制）特性，每层对应一个子卷快照，适合需要频繁回滚的场景；
- devicemapper：不基于目录，而是把每层映射为块设备上的精简快照，更重，但与 LVM 集成度高。
为什么不同驱动影响镜像行为
存储驱动决定了层怎么存、怎么读、怎么共享。同一份 Dockerfile，在不同驱动下可能产生不同的构建速度、磁盘占用甚至运行表现：
- 使用 overlay2 时，
RUN apt install生成的新层只记录变更内容，基础镜像层被多个镜像共用； - 在 devicemapper 下，每层会分配固定大小的逻辑卷，即使实际改动很小，也可能占用数 MB 空间；
-
btrfs 支持原子快照，
docker image prune -a可能触发子卷批量清理，而 overlay2 则需逐层校验哈希后删除。
如何确认和匹配驱动与分层需求
不是所有驱动都适合所有环境。选错会导致构建慢、空间浪费或兼容问题：
- 查看当前驱动：
docker info | grep "Storage Driver"； - 生产环境优先用 overlay2（要求 Linux 内核 ≥ 4.0，推荐 ≥ 5.4）；
- 旧版 Ubuntu（如 14.04）只能用 aufs，但已不被 Docker 官方推荐；
- 若宿主机用 Btrfs 文件系统且需镜像级快照管理，可显式配置 btrfs 驱动。
分层与驱动共同保障镜像不可变性
镜像层的只读性不是靠权限控制，而是由存储驱动强制实现：
- 所有镜像层在
lowerdir或等效位置以只读方式挂载； - 任何写操作都被重定向到可写层（
upperdir或容器层），原始层文件不会被覆盖或修改； - 层间覆盖规则（如上层同名文件屏蔽下层）由驱动在挂载时解析，不是 Docker 引擎自行判断。
