docker push 必须指定完整镜像名和标签（如 myapp:1.2.3），不会自动推送 latest 或其他标签；需确保本地存在该标签、已登录私有仓库（带地址前缀）、标签命名合法（仅含小写字母、数字、点、下划线、短横线且不以点或短横线开头结尾）；可用 docker tag 为同一镜像 ID 打多个标签并分别推送；标签本质是可变指针，可靠回滚应使用不可变的 digest。
docker push 怎么推指定标签的镜像
直接用 docker push 加带标签的镜像名，比如 docker push myapp:1.2.3。Docker 默认只推你明确写的那个标签，不会连带推送 latest 或其他标签——这点很多人误以为会“自动同步”，结果远程仓库里只有 latest，要的版本反而没上去。
常见错误现象：docker push myapp（不带标签）会报错 denied: requested access to the resource is denied 或提示“no tag specified”。Docker 要求必须指定完整镜像名+标签，不能省略。
- 确保本地镜像真有这个标签：运行
docker images | grep myapp看myapp:1.2.3是否存在 - 如果只是改了代码但没重新打标签，
docker build -t myapp:1.2.3 .这步不能跳 - 私有仓库需提前
docker login，且镜像名要带地址前缀，例如registry.example.com/myapp:1.2.3
怎么给同一个镜像打多个标签并分别推送
一个镜像 ID 可以绑定多个标签，用 docker tag 复制就行。这比重复构建快，也保证二进制一致性。
使用场景：上线前既要推语义化版本（myapp:v1.2.3），又要推分支快照（myapp:main-20240520），还要留个 myapp:stable 给运维拉取。
- 先构建基础镜像：
docker build -t myapp:build . - 打多个标签：
docker tag myapp:build myapp:v1.2.3、docker tag myapp:build myapp:main-20240520 - 分别推送：
docker push myapp:v1.2.3、docker push myapp:main-20240520 - 注意：
docker tag不复制层，只是加引用；但docker push每次都会检查远程是否已有对应层，已存在的不会重复传
镜像标签命名不规范导致的推送失败
Docker 对标签名有严格字符限制：只能含小写字母、数字、点（.）、下划线（_）、短横线（-），且不能以点或短横线开头或结尾。不符合就推不过去，报错类似 invalid reference format 或 bad request。
容易踩的坑：
- 用 Git commit hash 直接当标签？
docker tag app:8f3a2c7—— OK；但docker tag app:8f3a2c7-dirty就非法（末尾短横线） - 语义化版本写成
v1.2.3-beta.1是合法的；但v1.2.3+build.1中的加号（+）不被允许 - CI 脚本自动生成标签时，建议用
sed过滤掉非法字符，例如：git describe --tags | sed 's/[^a-zA-Z0-9._-]//g'
私有仓库中标签覆盖与不可变性的现实约束
多数私有 registry（包括 Harbor、GitLab Container Registry）默认允许覆盖同名标签，但这不是 Docker 协议强制要求的——它只是“删旧再传新”。一旦覆盖，旧镜像就彻底丢失，CI/CD 流水线可能拉到意外版本。
为什么这样做风险大：
-
docker pull myapp:latest拉到的可能是昨天的镜像，也可能是刚覆盖的、未经充分测试的新版 - Kubernetes 的
imagePullPolicy: IfNotPresent在节点已有该标签时不会校验内容一致性，容易引发环境漂移 - Harbor 等支持“项目级不可变标签”策略，启用后
v1.2.3标签一旦推送就不能再推同名——但需要手动打开，不是默认行为
真正关键的一点：标签（tag）本质是可变指针，不是版本快照。想靠标签做可靠回滚，得配合镜像 digest 使用，比如记录并拉取 myapp@sha256:abc123...——那才是不可变的。
