不会重传整个layer，Docker会跳过已上传的digest（需registry支持HEAD校验），仅重传失败或未开始的layer；token过期、网络代理截断或digest变更才是中断后无法跳过主因。
docker push 大镜像层上传中断后会重传整个 layer 吗？
不会自动断点续传，但 Docker 客户端实际行为比“全量重传”更聪明：它会跳过已成功上传的 layer digest，只重传失败或未开始的 layer。前提是 registry 支持 HEAD 请求校验（主流 registry 如 Docker Hub、Harbor、ECR 都支持），且本地 docker push 进程重启后仍能复用原有 layer cache。
常见错误现象：unauthorized: authentication required 或 error parsing HTTP response 中断后，再次 docker push 仍从头卡在同一个 layer；这通常不是重传问题，而是 token 过期或网络代理截断了长连接。
- registry 必须支持
HEAD /v2/<name>/blobs/<digest>返回200 OK+Docker-Content-Digestheader，Docker 才能跳过该 layer - 本地构建缓存（
/var/lib/docker/image/overlay2/...）不能被清理，否则 digest 对应的 layer 元数据丢失，会被当作新 layer 重新上传 - 使用
docker buildx build --push时，若启用--cache-to，不影响 push 行为，但 layer digest 生成逻辑更稳定，推荐用于大镜像
如何确认某 layer 是否已被 registry 接收？
直接查 registry 的 blob 状态最可靠，不需要依赖客户端日志。用 curl 模拟 Docker 客户端的 HEAD 请求即可验证：
curl -I \ -H "Authorization: Bearer $TOKEN" \ "https://<registry>/v2/<repo>/blobs/sha256:<digest>"
返回 200 OK 且含 Docker-Content-Digest header，说明该 layer 已存在；返回 404 Not Found，说明要重传；返回 401 Unauthorized，说明 token 失效，需重新登录或刷新 token。
-
$TOKEN不是docker login密码，而是通过curl调用 registry 的/v2/auth接口获取的 bearer token - layer digest 可从
docker images --no-trunc或构建日志中提取，注意是sha256:xxx全长，不是短 ID - 某些私有 registry（如老旧 Harbor 版本）禁用
HEAD方法，此时 Docker 无法跳过，必须等完整上传完成
上传中断频繁时，哪些参数能降低失败概率？
根本原因常是 TCP 连接空闲超时或 TLS 握手不稳定，不是 Docker 本身的问题。调整的是底层 HTTP 客户端行为，而非 docker push 命令开关：
- 设置环境变量
DOCKER_CLI_HINTS=0关闭提示干扰，避免误判进度卡死 - 在
~/.docker/config.json中增加"max-concurrent-uploads": 1，减少并发争抢连接（尤其在弱网或代理后） - 用
timeout命令包裹 push，避免挂起：timeout 7200 docker push myapp:large（单位秒） - 不推荐改
HTTP_PROXY直连 registry，除非明确知道代理支持长连接和 chunked transfer；否则优先走直连
用 skopeo copy 替代 docker push 能解决中断恢复吗？
不能自动续传，但 skopeo copy 提供更细粒度控制和明确失败点，便于手动干预。它按 layer 逐个上传，失败时停在具体 digest，你可以单独重试那个 layer：
skopeo copy \ --src-tls-verify=false \ --dest-tls-verify=false \ docker-daemon:myapp:large \ docker://myreg/myapp:large
对比 docker push，skopeo 不依赖本地 daemon 状态，适合 CI 环境或磁盘受限机器；但它也不缓存 registry 的 blob 状态，每次运行都重新 HEAD 校验，所以恢复逻辑本质相同，只是失败反馈更快、更透明。
- 必须确保
skopeo版本 ≥ 1.9.0，旧版本对 digest 校验不严格，可能重复上传 -
skopeo copy不触发构建，只做传输，因此不能替代docker build阶段的优化 - 如果 registry 启用了存储配额限制，单个 layer 上传失败后，部分 registry（如 ECR）可能残留未完成 upload 记录，需调用
POST /v2/<name>/blobs/uploads/清理，否则后续上传报400 Bad Request
真正影响恢复效率的，从来不是工具选型，而是 registry 的 blob head 接口是否稳定、网络路径是否存在静默丢包、以及 layer digest 是否因构建环境差异而意外变更——最后这点最容易被忽略：哪怕只改了一行注释，docker build 生成的 layer digest 就不同，之前传过的 layer 完全作废。
