改一行代码，不用重新下载整个镜像？Docker 镜像分层入门

第一次用 Docker 拉镜像的人，都会被它的下载过程惊到：进度条不是一条，而是一长串，每一串后面都跟着一串看不懂的哈希值。等你改了一行代码重新构建，更神奇的事情发生了——构建几乎是秒完成的，好像只重新处理了改动的那一小部分。

这就是 Docker 最核心的设计：镜像分层。

可以把镜像想象成千层饼。最底层是操作系统基础层，往上是运行环境层（比如 Python 3.12），再往上是依赖层（pip install 装的那些包），最顶上才是你自己的代码层。每一层都是只读的，构建时 Docker 按 Dockerfile 里的指令，从下往上一层一层叠加上去。

分层带来两个直接的好处。第一是缓存：构建时 Docker 会逐层检查内容有没有变化，没变化的层直接复用缓存，只有变化的那一层以及它上面的层才重新构建。所以写 Dockerfile 有一条军规：把不常变的东西（比如安装系统依赖、pip install）放在前面，把经常变的东西（比如复制业务代码）放在最后面。顺序写反了，每次改一行代码都要重装一遍依赖，构建慢到怀疑人生。

第二是省空间：同一台机器上的十个镜像，可能都基于同一个 Python 基础层，硬盘上这一层只存一份，大家共享。你用 docker images 看到的每个镜像大小是“逻辑大小”，实际磁盘占用要小得多。

新手最容易踩的坑也和分层有关：在一层里下载了安装包，下一层又把它删掉，以为省了空间，其实被删文件的那个层已经“定格”了，删除动作只会再叠一层“遮罩”，空间一分没省。正确做法是把下载、安装、清理写在同一个 RUN 指令里，让它们发生在同一层里，一气呵成。

理解了分层，你就理解了 Docker 一半的设计哲学：不变的东西沉到底，变化的东西浮上来。缓存、分发、回滚，全是这一个思想的展开。下次构建秒完成时，你就知道是谁在替你省时间了。