根本原因是Docker CLI不校验远程层是否存在，导致重复上传；buildx支持远程预检跳过已存在层，配合固定基础镜像和确定性构建可彻底解决。
为什么 docker push 总在传相同层？
根本原因不是网络慢，而是镜像层哈希没变但标签变了——Docker 默认不校验远程仓库是否已存在该层，只要本地有，就走上传流程。哪怕远端 registry 里 sha256:abc123... 已存在，它也照传不误。
常见错误现象：docker push 日志里反复出现 layer already exists，但前面仍花了几十秒上传；CI 构建后每次推镜像都耗时 2+ 分钟，即使只改了最后一层。
- 关键点：Docker CLI 本身不带“远程层预检”能力，依赖 registry 是否支持
HEAD /v2/.../blobs/<hash></hash>并正确响应200 - 私有 registry（如 Harbor、Nexus）默认开启该检查，但需确保配置了
blob mount支持且未被反向代理拦截HEAD请求 - Docker Hub 对匿名用户限制较严，频繁
HEAD请求可能被限流，反而拖慢整体速度
用 buildx build --push 替代传统 docker build && docker push
buildx 的构建器（builder）在推送前会主动探测远端是否存在对应层，跳过已存在的层上传——这是目前最可靠、开箱即用的优化方式。
使用场景：多平台构建（--platform linux/amd64,linux/arm64）、需要复用缓存、CI 中频繁推新标签。
- 必须启用 BuildKit：
DOCKER_BUILDKIT=1环境变量或写入~/.docker/buildkit - 构建器需支持
oci-mediatypes和push-by-digest，推荐用docker-container驱动而非默认docker - 命令示例：
docker buildx build --platform linux/amd64 --tag myapp:v1.2 --push .，注意必须带--push，单独--output type=image,push=true不触发层跳过逻辑
镜像命名和标签策略直接影响层复用率
同一层能否被跳过，取决于它的内容哈希是否与远端某次成功推送的层完全一致——而哈希受构建上下文、指令顺序、甚至空格影响。标签名本身不影响，但标签管理方式会间接破坏复用。
常见错误现象：每天打 v20240501 标签，但基础镜像（如 python:3.11-slim）每月更新一次，导致所有衍生层哈希全变；或用 latest 覆盖推送，引发 registry 内部层引用混乱。
- 固定基础镜像：用带 digest 的镜像名，例如
python:3.11-slim@sha256:7f9...，避免上游更新污染哈希 - 避免在
COPY或RUN中引入时间敏感内容（如date、git log -n1），除非用--build-arg BUILD_DATE=xxx并确保 CI 每次传相同值 - 不要用
docker tag后再push同一镜像——这会产生新 manifest，但层哈希不变，registry 可能拒绝挂载（尤其 Harbor 开启内容信任时）
调试层上传行为：看日志，别猜
光看终端里 “pushed” 字样没用，得确认每层是否真跳过了。Docker CLI 不输出详细层比对过程，但 buildx 和 registry 日志可验证。
实操建议：
- 加
--progress=plain参数运行buildx build --push，观察是否有=> exporting to image后直接=> pushing layers跳过上传步骤 - 在 registry 服务端查日志（如 Harbor 的
/var/log/harbor/core.log），搜索blob mount或mount blob from repository，出现即表示层复用成功 - 如果始终看到
Uploading layer+ 进度条，优先检查是否用了docker build而非buildx，或 builder 实例未重启导致 BuildKit 缓存失效
真正卡住的地方往往不在网络带宽，而在构建确定性 —— 层哈希变，再快的 registry 也救不了。这点容易被忽略，因为错误日志里从不提示“你这次构建和上次不一样”。
