答案是镜像分层共享机制。它通过内容寻址使多个镜像复用相同基础层，仅传输增量层，显著减少存储占用、网络开销和构建时间，并依托联合文件系统与写时复制保障运行时效率与一致性。
容器化服务的高效分发，核心不在“传得快”，而在“少传什么”。镜像分层不是技术装饰，而是部署加速的底层逻辑——它让重复内容只存一份、只拉一次、只构建一回。
分层共享直接减少网络传输量
镜像由多个只读层叠加而成，每一层对应 Dockerfile 中一条指令。当多个服务基于同一基础镜像（如 alpine:3.18 或 ubuntu:22.04）构建时，基础层在 Registry 中仅存储一次；客户端拉取时，若本地已存在该层，就跳过下载。
- 例如：10 个微服务都用
FROM python:3.11-slim，基础系统层 + Python 运行时层共约 45MB，只需下载 1 次 - 后续每个服务仅需传输自己独有的代码层、配置层等增量部分（通常几 MB），而非重复拉取上百 MB 的完整镜像
- 使用
docker pull时，控制台显示的 “Already exists” 就是层复用的直观体现
构建阶段靠层缓存提速，而非单纯拼硬件
Docker 构建时按顺序执行指令，一旦某层命中缓存，其后所有依赖层可直接复用。这意味着：改动越靠近 Dockerfile 底部，重建越快。
- 把变动频繁的操作（如
COPY . .）放在后面，稳定操作（如系统更新、依赖安装）放在前面 - 避免在
RUN中混写多个无关命令（如apt update && apt install && rm -rf /var/lib/apt/lists/*），否则任一子命令变更都会使整层失效 - 多阶段构建中，构建阶段产生的中间层不打入最终镜像，既减小体积，又避免污染运行时缓存
私有仓库 + 分层校验，确保加速不降质
加速不能以牺牲一致性为代价。国内常用镜像加速方案（如 DaoCloud、阿里云 ACR 镜像代理）本质是透明缓存 + 哈希校验：
- 镜像拉取请求被重定向到就近 CDN 节点，节点本地无对应层时，才向上游同步并持久化
- 每层上传/下载均校验 SHA256 摘要，哪怕一个字节差异也会触发重新获取，杜绝“脏缓存”风险
- 企业可结合 TCR 或 Harbor 设置命名空间级权限，让 dev/test/prod 环境复用同一套基础层，但隔离应用层推送权限
运行时优化：利用可写层最小化 I/O 开销
容器启动后，Docker 在只读镜像层顶部挂载一个可写层（Container Layer）。所有文件修改都通过写时复制（CoW）发生在此层：
- 日志、临时文件、运行时生成配置应明确写入可写层路径（如
/tmp、/app/runtime），避免反复覆盖只读层文件触发复制 - 若应用频繁读写大文件（如数据库），建议挂载 hostPath 或 PVC，绕过 CoW 机制，防止可写层膨胀拖慢启动
- 用
docker diff <container_id></container_id>可查看哪些文件被复制进可写层，辅助识别潜在 I/O 瓶颈
