写时复制（Copy-on-Write）是延迟复制机制，仅在文件首次被修改或删除时才将只读层中对应文件完整复制到可写层，原文件保持不动仅被遮蔽；其按文件粒度复制，非字节或块级，导致大文件修改时upperdir迅速膨胀。
写时复制不是“实时备份”，而是“改前才拷”
写时复制（Copy-on-Write）机制的本质，是延迟复制：只要文件没被修改，就永远不从只读层把它拉上来。容器启动时，lowerdir里堆着所有镜像层（只读），upperdir是空的；只有第一次 touch /app/config.json 或 echo "new" > /app/log.txt 这类写操作发生时，Docker 才把原始文件从某一层完整复制到 upperdir，再在副本上写入——原层里的文件一动不动，只是被遮住了。
常见错误现象：
– 容器内反复读取大文件（如 /usr/lib/libc.so.6）毫无性能损失 → 正常，没触发 COW
– 用 find / -name "*.log" -delete 清日志后镜像体积暴涨 → 错误，删除操作也会触发 COW：每个被删文件先被复制进 upperdir，再标记为“已删除”，实际空间未释放
– 多个容器同时写同一个路径（如 /tmp/cache），彼此看不到对方改动 → 正确，COW 是 per-container 的，upperdir 不共享
为什么 COPY 指令放错位置会让缓存全失效？
Docker 构建缓存依赖分层顺序，而 COW 的底层逻辑决定了：只要某一层变了，它上面所有层都得重建。比如这个典型陷阱：
COPY . /app/ RUN npm install
只要源码任意一个文件变动（哪怕只是改了 README.md），COPY 层就会变，导致后续 RUN npm install 无法复用旧缓存——明明 node_modules 没变，也得重装。
正确做法是把变少的部分提前：
-
COPY package*.json ./→ 只有依赖声明变才触发下一层 -
RUN npm install --production→ 缓存稳定 -
COPY . .→ 放最后，不影响前面层
这不只是“快一点”的问题：在 CI/CD 中，一次无效缓存可能让构建时间从 20 秒跳到 6 分钟，且生成的镜像层 ID 全新，推送到 registry 时无法复用已有层。
overlay2 的 lowerdir/upperdir/merged 怎么查？
运行中的容器，它的文件系统视图就是 COW 的实时体现。你可以直接看宿主机上的挂载信息来验证：
执行：mount | grep overlay
输出类似：overlay on /var/lib/docker/overlay2/labcde.../merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/123.../diff:/var/lib/docker/overlay2/456.../diff,upperdir=/var/lib/docker/overlay2/labcde.../diff,workdir=/var/lib/docker/overlay2/labcde.../work)
其中：
– lowerdir 是冒号分隔的多个只读层路径，对应 Dockerfile 中 FROM 到上一个 RUN/COPY 的所有层
– upperdir 就是那个可写层，容器所有新增、修改、删除都发生在这里
– merged 是你进容器看到的 / 根目录
注意：docker inspect <container-id> 里 GraphDriver.Data 字段也能看到这些路径，但不如 mount 直观。
写时复制对磁盘空间和删除操作的影响
COW 让多个容器共享镜像层，节省空间，但代价是：删除操作不真正删数据，只是“隐藏”。例如：
容器内执行：rm -rf /node_modules
实际效果是：每个 /node_modules/xxx 文件都被复制进 upperdir 并打上“已删除”标记，原始只读层里的 /node_modules 还在，upperdir 却多了一堆元数据 —— 镜像体积反而增大。
更隐蔽的问题：
– docker system prune -a 不会自动清理已“删除”但还占着 upperdir 空间的文件
– 容器退出后，upperdir 随之销毁；但如果你用 docker commit 把它固化成新镜像，那些被“删掉”的文件就真的进了新层，永远占地方
所以，别在容器里靠 rm 节省空间；真要清理，应在构建阶段用多阶段构建（multi-stage build）或 RUN find /tmp -type f -delete && apt-get clean 这类只读层内操作。
最易被忽略的一点：COW 的“复制”是按文件粒度，不是块或字节。改一个 1KB 的配置文件，会把整个原始文件（比如 2MB 的二进制）复制上来——这对大文件频繁修改的场景，upperdir 膨胀极快，且不可逆。
