UnionFS性能瓶颈在于路径查找延迟高、COW效率低、层合并耗时长；Overlay2通过index文件、ROW机制和内核原生支持优化；建议切换驱动、精简Dockerfile、启用BuildKit与缓存。
UnionFS 是 Docker 早期默认的存储驱动，其分层叠加机制虽支撑了镜像构建的轻量性和复用性，但在构建密集型场景下会显著拖慢性能——尤其在多层写入、频繁 COPY、大量小文件操作时，层间合并开销和元数据遍历成本会急剧上升。
UnionFS 的性能瓶颈在哪
UnionFS（如 aufs、overlay 的早期版本）采用“上层可写 + 下层只读”的堆叠结构。每次构建新层，都要在所有下层中逐层查找文件，再进行 copy-on-write（COW）或重定向。这带来三类典型开销：
- 路径查找延迟高：一个文件访问需遍历全部只读层，层数越多越慢（例如 20 层镜像，每次 stat 可能触发 20 次元数据检查）；
- COW 效率低：修改小文件时需整份复制到上层，磁盘 I/O 和内存占用陡增；
- 层合并耗时长：docker build 中每条 RUN 指令生成一层，最终 docker commit 或镜像导出时需递归合并所有层，易成构建瓶颈。
用 Overlay2 替代 UnionFS 是最直接优化
Overlay2 是目前 Docker 官方推荐且默认的存储驱动，它从设计上规避了传统 UnionFS 的多数缺陷：
- 仅支持最多 128 层（实际够用），且使用更高效的 index 文件管理硬链接，大幅减少查找路径次数；
- 支持 “redirect-on-write”（ROW）机制，在部分场景下避免整文件复制；
- 内核原生支持（Linux 4.0+），无需额外模块，稳定性与性能均优于 aufs 或旧版 overlay。
确认当前驱动：docker info | grep "Storage Driver"；若显示 overlay 或 aufs，建议升级 Docker 并切换至 overlay2（需确保系统内核 ≥ 4.0，/var/lib/docker 迁移前请备份）。
构建阶段主动减层、合层、避层
即使使用 overlay2，不合理的 Dockerfile 写法仍会放大底层开销。关键原则是：让每一层尽可能“厚”而“少”，并减少跨层文件传递：
- 合并 RUN 指令：将 apt update && apt install && rm -rf /var/lib/apt/lists/* 写在同一行，避免产生中间层残留缓存；
- 用 .dockerignore 过滤无用文件：防止大量日志、node_modules、.git 等冗余内容被 COPY 进镜像，减少 COW 触发面；
- 优先用多阶段构建（multi-stage）：编译环境与运行环境分离，最终 stage 只 COPY 编译产物，彻底跳过中间层打包和合并；
- 避免在构建末期 COPY 大目录：如必须，考虑先 tar 压缩再解压，比逐文件 COPY 更少触发元数据更新。
配合构建工具进一步提效
单靠存储驱动和 Dockerfile 优化仍有天花板。可引入外部加速机制：
- 启用 BuildKit：设置 DOCKER_BUILDKIT=1，它提供并行构建、更好的缓存命中（基于指令内容而非层顺序）、以及对 cache mount 的原生支持；
- 挂载构建缓存：用 --cache-from 复用远端镜像层，或搭配 registry 缓存（如 ghcr.io 或自建 Harbor）；
- 用 docker buildx 构建多平台镜像时复用缓存：通过 --cache-to 将构建结果推回 registry，供后续 CI 流水线拉取复用。
