Docker存储架构以镜像分层、写时复制（CoW）和可插拔存储驱动为三大支柱，overlay2为当前Linux主流默认驱动，通过upperdir（可写层）、lowerdir（只读层）和merged（统一视图）实现高效隔离与复用。
直接从分层结构和写时复制机制入手最有效。Docker 存储不是抽象概念，而是有明确的目录组织、文件层级和内核交互逻辑，边看边操作比纯读文档快得多。
先搞懂镜像和容器的三层物理结构
打开宿主机终端，运行 docker info | grep "Storage Driver" 确认当前驱动（大概率是 overlay2）。接着进到 /var/lib/docker/overlay2/ 目录下，你会看到一堆随机字符串命名的子目录。每个目录对应一个镜像层或容器层：
- lowerdir：只读镜像层，按构建顺序堆叠，越靠下越基础（如 debian:bookworm）
- upperdir：容器自己的可写层，所有新增或修改的文件都落在这儿
- merged：最终挂载给容器使用的统一视图，对容器来说就像一个普通根文件系统
动手验证写时复制（CoW）行为
起一个容器：docker run -it --rm ubuntu:22.04 bash，在里头创建一个文件并改写一个系统文件：
- touch /tmp/test.txt → 这个文件会立刻出现在 upperdir 对应目录中
- echo "hello" > /etc/hostname → 原本 /etc/hostname 在只读镜像层，Docker 会先把它复制到 upperdir，再修改
- 退出后重跑同命令，/tmp/test.txt 消失，/etc/hostname 恢复原样 → 验证了容器层生命周期绑定容器实例
对比不同存储驱动的实际差异
overlay2 是默认且推荐的，但理解它为什么比 aufs 或 devicemapper 更优，关键在两点：
- 内核原生支持：overlayfs 自 Linux 4.0 起内置，无需额外模块，稳定性高
- 128 层限制宽松：足够覆盖绝大多数 Dockerfile 构建深度；aufs 通常限 127 层，devicemapper 在 loop-lvm 模式下性能衰减明显
- 如果用的是 CentOS 7 或旧内核，可能默认 fallback 到 devicemapper，这时 docker info 里会显示 WARNING 提示不推荐用于生产
把卷（Volume）和存储驱动区分开
初学者容易混淆“容器层写入”和“数据持久化”。记住：
- 存储驱动管的是 镜像怎么存、容器层怎么写，属于 Docker 引擎内部机制
- 卷（Volume）是独立于存储驱动的外部路径管理方式，数据存在 /var/lib/docker/volumes/ 下，不受容器删除影响
- 比如 docker run -v mydata:/app nginx，mydata 卷的数据不会被 overlay2 的 CoW 机制处理，它是绕过容器层直接映射的
