先记住这个答案
镜像层是文件系统变更集，创建后只读。多个层通过联合挂载组成统一视角。不同镜像可共享相同基础层，减少存储与传输。容器启动时增加可写空白层，所有写操作在可写层进行，删除容器后写层随之消失，镜像层保持不变。
- 镜像层只读且不可变
- 层共享降低存储与分发成本
- 容器写层隔离，不影响镜像
层如何叠加成完整文件系统
每个镜像层只包含一组文件系统变化，比如安装包时新增的文件或修改的配置。构建工具把这些差异打包为只读层，并赋予基于内容的唯一 digest。当多个镜像拥有相同内容的层时，存储端只保存一份，拉取时通过 digest 校验复用。
启动容器时，Docker 将各镜像层按顺序挂载到同一挂载点，形成统一的只读视图。同时创建一个空白可写层覆盖其上。所有写操作落在该层，读取时若可写层没有找到文件则向下查找。删除文件通过创建删除标记（whiteout）隐藏，但下层数据并未被修改。
多服务共享基础镜像的落地场景
假设团队用 ubuntu:22.04 作为基础镜像构建 Python 服务和 Go 服务。两个 Dockerfile 都从同一基础镜像开始，后续各自添加依赖和应用代码。CI 中先后构建两个镜像，第一条构建拉取基础层后，第二条构建可直接复用本地已有层，无需重新下载。
推送至仓库时同理：若仓库已有该基础层，新镜像只需上传新建的差异层。假定基础层 800MB，服务层各 50MB，两个镜像在注册表的总占用约 900MB，而非 1.7GB。即使基础镜像升级，若底层多数层未变，仍能保存部分共享空间。
层共享的适用边界与失效条件
层只读和共享依赖存储驱动的联合挂载能力，但不同驱动的层数上限与性能特征不同。例如某些旧驱动对层数敏感，层数过多会使写时复制变慢。即使使用推荐驱动，极端层数也可能影响构建或启动时的元数据解析。
只读特性在镜像分发和运行时有效，但构建过程中若使用临时写层，则可能需要显式 commit 才固化。此外，容器删除时其写层被丢弃，镜像层本身保留。若误以为容器内修改会回流到镜像，则需重构镜像或改用额外提交。
容易答错的地方
- 误以为层是完整快照
- 层只保存自上一层以来的变更，不包含完整文件。例如一个基础系统层可能只包含新增的目录和文件，体积远小于解压后的全量目录。只有所有层叠加后才呈现完整根文件系统。
- 误以为容器修改会覆盖镜像层
- 容器中的写入全部落在可写的临时层，底层只读层在生命周期内不变。容器退出后写层被丢弃，除非显式执行
docker commit生成新层。若没有提交，所有修改不会沉淀为镜像数据。
面试官还会怎么问？
容器修改文件时如何不影响镜像层？
通过写时复制策略：修改文件前，先从只读区域将文件复制到容器写层再改动，底层原文件不变。同一镜像启动的多个容器各有独立写层，互不干扰。删除操作则通过写删除标记隐藏。
docker commit 会创建新镜像是如何工作的？
docker commit 会把当前容器的可写层整体打包成一个新镜像层，与底层镜像层组合成新镜像。该操作不会修改原有镜像层，只是新增一个差异层。常用但 Dockerfile 更可复现。
为什么 RUN rm 文件不一定减小镜像体积？
镜像层记录的是变更，删除标记位于新层，但被删除文件的原数据仍然留在早前层中。拉取镜像时这些层都会存在，因此实际传输体积不一定缩小。要真正减小只能重建或重排层。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。