Docker镜像分层结构直接影响存储驱动性能：overlay2适合层数多但修改集中于顶层的场景，支持硬链接共享只读层；RUN指令过碎或中间层频繁变更会降低aufs和devicemapper性能；高复用基础镜像下overlay2和fuse-overlayfs可节省30%~60%磁盘空间；高频小文件写入推荐overlay2，需快照或配额则选zfs/btrfs；Linux 4.0+ ext4环境下overlay2为默认最优解。
镜像层级结构不是静态背景，而是直接影响存储驱动表现的核心变量。选型不能只看“支持列表”，得从层怎么建、怎么变、怎么用出发来匹配驱动特性。
看镜像层数量和变更集中度
层数多、但修改基本只发生在最上层（比如日志写入、临时缓存），这种结构对 overlay2 最友好。它用硬链接共享只读层，元数据开销小，启动快、空间省。
- 如果 Dockerfile 中 RUN 指令拆得太碎，导致几十层，又经常在中间层改配置——aufs 会明显变慢（mount/unmount 耗时陡增），devicemapper 容易触发 thin-pool 扩容和碎片
- 若业务要求频繁重建中间层（如 CI/CD 中动态注入版本号或密钥），建议用 overlay2 + fuse-overlayfs 用户态挂载，能更精细控制 inode 生命周期
看基础镜像复用率
企业里 python:3.11-slim、node:20-alpine 这类基础镜像往往被几十个业务镜像共用。这时候层复用效率直接决定磁盘占用和拉取速度。
- overlay2 和 fuse-overlayfs 原生支持跨镜像硬链接：相同内容哈希的层只存一份，实测节省 30%~60% 磁盘空间
- btrfs 虽支持 CoW，但需手动 balance 清理未引用块；zfs 若 recordsize≠4K 或开启压缩，反而破坏层哈希一致性，导致重复存储
看运行时写负载特征
容器启动后，可写层承受的实际 I/O 类型决定驱动稳定性。高频小文件写入、随机覆盖、大量 create/unlink 操作，不同驱动响应差异很大。
- 日志服务、API 网关类容器常有高频率追加写，overlay2 的 upperdir 设计对此优化充分；devicemapper 在小文件场景下延迟上升明显
- 若需快照回滚、配额限制或端到端校验，zfs/btrfs 是更合适的选择，但必须接受额外运维成本：zfs 需管理存储池，btrfs 需定期 scrub
看宿主机环境约束
再好的驱动，不匹配底层环境也白搭。内核版本、根文件系统、是否容器化部署，都会形成硬性门槛。
- Linux 4.0+ + ext4 文件系统 → overlay2 是默认且最优解，零配置即用
- 旧版 Ubuntu（如 14.04）或某些定制内核缺 OverlayFS 支持 → 只能退到 aufs（已不推荐）或考虑 vfs（仅调试）
- 使用 ZFS/Btrfs 作为宿主机根文件系统 → 对应存储驱动可直通利用原生特性，但需确认内核模块加载和权限配置
