镜像是只读层叠的 tar 包集合，非虚拟机快照；每个 layer 记录文件差分，运行时叠加并挂载可写层；FROM 多次写仅生效最后一个，docker commit 会打包全部可写层导致臃肿。
镜像不是虚拟机快照，是只读层叠的 tar 包集合
很多人第一次拉 docker pull ubuntu:22.04 后以为得到了一个“轻量系统”，其实拿到的是一堆按顺序排列的只读 tar 文件（即 layer），每个 layer 记录了文件增删改的差分内容。Docker daemon 用 overlay2（或 aufs、zfs）在运行时把它们叠加起来，再挂一个可写层（container layer）供容器修改。
这意味着：
– 镜像本身从不运行，也不含内核、init 进程或网络栈
– 所有 layer 按顺序叠加，靠后 layer 中同名文件会覆盖前面的
– 你执行 docker history nginx:alpine 看到的每一行，基本对应一个 layer 的构建指令
为什么 FROM 多次写不会叠加出新镜像？
因为 Dockerfile 中每个 FROM 都会重置构建上下文：前一个阶段的所有 layer 被丢弃，只保留最终 export 出来的文件（如用 COPY --from=0）。这不是“继承”，而是显式搬运。
常见误操作：
– 在单个 Dockerfile 里写多个 FROM 却没用 --from 引用前一阶段 → 前面的 FROM 完全无效
– 以为 FROM alpine:3.18 + FROM debian:12 会合并两个基础系统 → 实际只生效最后一个 FROM
– 多阶段构建中漏掉 COPY --from=builder /app/binary /usr/local/bin/ → 运行镜像里根本没二进制文件
docker commit 生成的镜像为什么总比预期大？
因为 docker commit 会把整个容器可写层打包成一个新 layer，包括所有临时文件、缓存、日志、甚至你 apt install 后没清理的 /var/lib/apt/lists/。它不识别语义，只做快照。
安全且轻量的做法：
– 绝对避免用 commit 生成生产镜像
– 构建必须走 Dockerfile + docker build，让每步都可控、可复现
– 如果真要保存状态（比如调试中装好依赖的环境），先手动清理：rm -rf /var/cache/apk/* /var/lib/apt/lists/* /tmp/*，再 commit
– 注意：commit 不会保留 ENTRYPOINT 或 CMD，得手动加 -c '["/bin/sh"]' 参数指定启动命令
只读层不能改，但为什么 docker run -v /host:/container 还能写？
因为 volume 挂载发生在容器启动时，绕过了镜像 layer 叠加逻辑。宿主机路径（/host）和容器内路径（/container）是两个独立的文件系统视图，写操作直接落在宿主机上，跟镜像的只读层完全无关。
关键区别：
– 写 /app/data.txt（在镜像 layer 里）→ 报错或触发 copy-on-write 到可写层（仅限 overlay2 支持）
– 写 /host/data.txt（已用 -v 挂载）→ 直接写宿主机磁盘，镜像层无感知
– tmpfs 类型挂载（--tmpfs /run）也是类似原理：内存文件系统，不经过 layer 栈
– 错误认知：“挂载后就能改基础镜像”→ 实际改的是挂载点，原 layer 依然不可变
最常被忽略的一点：layer 的哈希值由内容决定，哪怕只是多一个空格、换一行，就会生成全新 layer。所以构建缓存失效往往不是因为命令变了，而是某条 RUN 指令的输入（比如 curl 下载的包版本）变了 —— 这种变化无法从 Dockerfile 表面看出。
