docker镜像推送不自动压缩，需通过构建瘦身、导出压缩和分层复用协同优化：一、构建阶段用轻量基础镜像、多阶段构建、清理缓存；二、导出时可用docker save | gzip压缩；三、推送时依赖层复用机制提升效率。
Docker 镜像本身在 docker push 过程中不会自动压缩，但推送前的体积直接影响传输效率和成功率。真正起作用的是：推送前把镜像体积做最小化处理 + 推送时复用已上传层（非压缩，而是分层传输优化）。也就是说，“压缩体积”不是靠 push 命令实现的，而是一套构建+导出+传输协同的策略。
下面从三个关键环节说明怎么做：
一、构建阶段就大幅瘦身（最有效）
这是减小推送体积的根本，占效果的 80% 以上：
使用轻量基础镜像
比如把ubuntu:20.04（70MB+）换成alpine:latest（约 5MB），或更极致的gcr.io/distroless/static-debian12（约 3MB）采用多阶段构建
编译环境（含 Go/Java/Maven）只用于构建，最终镜像只复制二进制文件或 jar 包，不带任何编译工具链-
合并 RUN 指令并清理缓存
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
或 Alpine 下：
RUN apk add --no-cache ca-certificates tzdata && cp -f /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
避免 COPY 整个目录
只复制运行必需的文件，排除.git、node_modules（若前端已构建）、test/、docs/等
二、导出时用管道压缩（适合离线传输或备份）
如果要保存镜像为文件再传到另一台机器（比如内网部署），可用 docker save | gzip：
docker save myapp:prod | gzip > myapp-prod.tar.gz
这个 .tar.gz 文件比原始 tar 小很多（通常压缩率 2–4 倍），解压后仍可 docker load：
gunzip -c myapp-prod.tar.gz | docker load
注意：这不适用于 docker push，因为 registry 不接受 .tar.gz，只认原生镜像格式。
三、推送时的“隐式优化”机制
docker push 实际上传的是镜像的每一层（layer），不是整个打包文件：
- 如果某一层之前已推过（比如 base 镜像
alpine:latest），Docker 会跳过上传，只传新增层 - 所以镜像越小、层越少、复用率越高，推送越快
- 单层大小不能超过 registry 限制（常见是 10GB），否则 push 失败；瘦身也能规避这个问题
如果你遇到 denied: Authenticate Error 且伴随大层上传中断，大概率是网络不稳定或镜像层过大导致认证超时，此时优先检查是否用了臃肿基础镜像或未清理构建缓存。
不复杂但容易忽略
