docker镜像压缩需按场景匹配策略：构建用zstd平衡体积与性能，分发用gzip保障兼容性，调试禁用压缩；registry可结合squashfs+zstd提升存储密度；根本优化在于多阶段构建、精简基础镜像和.dockerignore排除冗余。
在 Docker 镜像仓库（如 Harbor、自建 Registry 或 Buildx 构建输出）中，存储压缩算法的选择直接影响镜像体积、拉取速度、CPU 开销和分发效率。关键不是“全局启用高压缩”，而是按场景匹配压缩策略——比如构建时用 zstd 平衡体积与解压性能，分发时用 gzip 保障兼容性，调试时禁用压缩节省 CPU。
Buildx 构建阶段：用 --compress 精准控制输出压缩
Buildx 是目前最主流的构建工具，支持在导出镜像时直接指定压缩方式：
- compress=gzip：默认推荐，压缩率中等、解压快、所有客户端都支持，适合 CI/CD 流水线和日常推送
- compress=zstd：需 Buildx v0.10+，压缩率比 gzip 高 20%–30%，解压速度接近，但部分旧版 Docker 客户端需升级才能拉取
- compress=disabled：跳过压缩，构建后立即可用，适合本地快速验证或调试，不占 CPU 但体积大
示例命令：
--platform linux/amd64 \
--output type=tar,dest=app.tar.gz,compress=zstd \
.
Registry 层面：启用 ZSTD + SquashFS 提升存储密度
对于长期归档或私有镜像仓库（如 Harbor 或自建 Registry），可在存储后端启用更底层的压缩技术：
- SquashFS 将整个镜像层打包为只读压缩文件系统，配合 ZSTD 可实现 2:1 以上空间压缩比
- 该方案对 CPU 影响集中在镜像首次加载时，后续读取走内核页缓存，I/O 效率反而提升
- 适用于离线部署包、Air-Gap 环境或边缘节点镜像预置场景
运行时镜像层优化：减少冗余层本身才是根本
压缩算法只是“补救”，真正降低空间与 CPU 双开销的方式是让镜像层更干净：
- 用多阶段构建（multi-stage build），只复制最终二进制，不带编译器、源码、文档
- 基础镜像选 distroless 或 alpine，避免 Ubuntu/Debian 的完整发行版冗余
- 通过
.dockerignore排除 node_modules、__pycache__、.git 等非必要文件，防止它们意外进入镜像层
日志与临时数据：别让非镜像内容挤占存储
镜像仓库本身的日志、上传缓存、GC 临时文件也会膨胀磁盘。建议单独配置：
- Registry 日志使用
logrotate + gzip自动轮转压缩，7 天日志可压缩至原大小 10%–20% - 定期执行
registry garbage-collect清理未被引用的 blob，配合--delete-untagged参数释放空间 - 将 registry 存储挂载到支持透明压缩的文件系统（如 btrfs 或 ZFS），在文件系统层统一压缩
