“denied: requested access to the resource is denied”是权限或命名空间不匹配所致，需确保镜像tag严格匹配远程路径（如ghcr.io/myorg/myapp:latest）、docker login针对对应registry（如ghcr.io）、token具备必要权限，且账号在私有registry中被授予目标项目角色。
push 镜像时 docker push 报错 “denied: requested access to the resource is denied” 怎么办
这是权限或命名空间不匹配的典型信号，不是网络或登录失效那么简单。
常见错误现象：docker push myapp:latest 失败，但 docker login 显示已成功；或者能推 username/repo 却推不了 orgname/repo。
- 确认镜像 tag 是否严格匹配远程仓库路径：比如你属于 GitHub Container Registry 的 org
myorg，那必须打 tag 为ghcr.io/myorg/myapp:latest，不能只写myapp:latest或ghcr.io/myapp:latest - 检查
docker login是否针对对应 registry：GitHub 需要docker login ghcr.io -u USERNAME，且 token 必须带read:packages、delete:packages、write:packages权限 - 私有 registry 若启用了 namespace 级别 ACL（如 Harbor），确保你的账号被显式授予目标项目（project）的
maintainer或developer角色
批量 push 多个镜像，用 shell 脚本循环调用 docker push 安全吗
安全，但默认行为下极容易因单点失败导致后续全部中断，且缺乏状态反馈。
使用场景：CI/CD 流水线末尾统一推送构建好的镜像列表；日常运维中同步测试环境镜像到预发环境。
- 务必在脚本开头加
set -e和set -o pipefail，否则某次 push 失败后脚本仍会继续执行，掩盖问题 - 每个
docker push后加判断：例如if ! docker push "$img"; then echo "FAIL: $img"; exit 1; fi，避免静默跳过 - 不要把镜像名硬编码进 for 循环，改用文件读取（如
while read -r img; do ... done ），方便复用和审计 - 注意 shell 中变量未引号包裹的风险：
docker push $img在镜像名含空格或特殊字符时直接崩，必须写成docker push "$img"
docker push 很慢，批量时怎么控制并发和超时
默认串行 + 无超时，既拖慢整体耗时，又可能卡死在某个坏镜像上。
性能影响：单个大镜像（>1GB）上传失败重试默认 5 次，每次间隔递增，总等待可达数分钟；并发过高则可能触发 registry 的连接数限制（如 Docker Hub 免费账户限 5 并发）。
- 用
timeout包裹单次 push：if ! timeout 600 docker push "$img"; then echo "Timeout pushing $img"; fi - 并发控制推荐用
parallel（非 GNU parallel 也行，但需确认版本支持--retries）：cat images.txt | parallel -j 3 docker push，-j 3表示最多 3 个并发 - 避免在 CI 环境中盲目提高并发数——runner 的出向带宽、registry 的 rate limit、以及本地磁盘 I/O 都可能成为瓶颈
镜像名动态生成时，docker tag 和 docker push 的顺序与参数差异
顺序错了会 push 错镜像，tag 参数写错会导致 registry 拒收或覆盖错误版本。
参数差异关键点：
-
docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]：SOURCE 可以是本地镜像 ID（如a1b2c3d4）或已有 tag；TARGET 必须包含完整 registry 地址（如ghcr.io/myorg/app:v1.2），否则 push 会默认发往 Docker Hub -
docker push TARGET_IMAGE[:TAG]：只接受已存在的 tag，且必须和docker tag中的 TARGET 完全一致（包括 registry 前缀） - 常见错误：先
docker tag app:v1 ghcr.io/myorg/app，再docker push ghcr.io/myorg/app:v1—— 这里 tag 后没指定新 tag 名，实际生成的是ghcr.io/myorg/app:latest，而 push 却指定了:v1，必然失败 - 建议统一用
docker tag app:v1 ghcr.io/myorg/app:v1，再docker push ghcr.io/myorg/app:v1，显式对齐
真正麻烦的是 registry 认证凭证在不同平台间的格式差异——GitHub、GitLab、Harbor、ECR 对 token 类型、登录命令、甚至 ~/.docker/config.json 中的 auth 字段编码方式都不一样。脚本里别试图“通用适配”，按目标 registry 单独处理登录逻辑更稳。
