unionfs是镜像共享的底层机制，镜像层为只读增量快照，每层对应dockerfile指令变更，以sha256哈希命名存储；容器运行时叠加可写层，通过写时复制（cow）实现修改隔离与底层共享。
联合文件系统（UnionFS）不是镜像共享的“结果”，而是让共享真正落地的底层机制。理解它，关键不是背概念，而是看清数据块在层与层之间如何被识别、复用和隔离。
镜像层本质是只读的数据块集合
每个镜像层对应 Dockerfile 中一条指令（如 FROM、RUN、COPY），它不存完整文件系统，只存自上一层以来的“变化”——新增文件、修改内容、删除路径。这些变化被打包成一个只读目录，以 SHA256 哈希值命名，存放在 /var/lib/docker/overlay2/ 下。多个镜像若共用某层（比如都基于 debian:12-slim），Docker 就只保留一份该层的物理数据，所有引用它的镜像都指向同一个目录。
- 执行 docker image history nginx:latest 可直观看到每层大小和生成命令，验证“层即差异”
- 运行 docker inspect nginx:latest --format='{{.RootFS.Layers}}' 能直接输出各层哈希，确认是否与其他镜像重叠
- 不同镜像间只要某层哈希一致，就自动共享，无需人工干预或配置
写时复制（CoW）保障共享安全与运行独立
容器启动时，Docker 在镜像层顶部叠加一个可写层（upperdir）。所有运行时改动——比如日志写入、临时配置修改、上传文件——都发生在这个层里。原始镜像层完全不动。
- 当容器内修改 /etc/nginx/conf.d/default.conf，UnionFS 会把该文件从只读层复制到可写层再编辑，原层文件不受影响
- 多个容器基于同一镜像启动，它们的可写层彼此隔离，互不干扰，但底层只读层完全共享
- 这种设计让镜像天然具备不可变性：你删掉某个容器，它的可写层随之销毁，镜像层毫发无损
挂载视图统一，但物理存储高度分离
UnionFS 把所有只读层 + 可写层，通过 overlay2 驱动挂载为一个 merged 目录（如 /var/lib/docker/overlay2/abc123.../merged），这就是容器看到的 /。进程读写文件时，完全感知不到背后十几层叠加；但实际访问路径由 UnionFS 动态解析：先查最上层（可写层），命中则返回；未命中则逐层向下查找，直到找到第一个匹配项。
- 同名文件天然被上层覆盖：比如基础层有 /bin/bash，应用层 COPY 过来新版 /bin/bash，容器里就只能看到新版
- 删除操作也通过 whiteout 文件标记实现——在可写层创建特殊隐藏文件，屏蔽下层同名项，不真正删原始数据
- 这种“逻辑统一、物理分散”的结构，是构建、分发、运行解耦的技术根基
构建缓存与拉取优化都依赖层哈希一致性
Docker 判断是否复用某层，唯一依据是该层构建上下文的哈希值。只要 FROM 指令、前序 RUN 命令、源文件内容完全一致，生成的层哈希就相同，就能复用本地已有层。
- CI/CD 中反复构建时，如果 COPY package.json 和 RUN npm install 中间没有变更，npm install 层就会被缓存跳过
- 镜像拉取时，Docker daemon 对比远程 registry 中各层哈希与本地是否存在，仅下载缺失层，大幅减少网络传输
- 镜像瘦身的关键，就是减少不必要的层变更——比如合并 RUN 命令、避免 COPY 后又 RUN rm
