严格来说，并不是每次都必须执行 docker tag 命令才能进行 docker push，但推送的镜像必须拥有一个符合目标仓库命名规范的标签（Tag）。
之所以在实际操作中经常看到"先 tag 后 push"的流程，是因为 Docker 的推送机制依赖于镜像名称中携带的仓库地址信息。以下是详细原理解析：
- 核心原因：Docker 需要知道"推送到哪里"
Docker 镜像的完整标识格式为：
注册表地址(Registry)\]/\[命名空间(Namespace)\]/\[镜像名(Repository)\]:\[标签(Tag)
默认行为：如果你构建镜像时只用了简单名字（如 myapp:v1），Docker 默认认为该镜像属于 Docker Hub 的官方库或当前用户未指定命名空间。
推送规则：当你执行 docker push 时，Docker 客户端会解析镜像名称中的注册表地址。
如果名称中包含私有仓库地址（如 harbor.example.com/myproj/myapp:v1），Docker 就会推送到该私有仓库。
如果名称中不包含地址（如 myapp:v1），Docker 默认尝试推送到 Docker Hub (docker.io)。
因此，docker tag 的本质作用不是"修改镜像"，而是给本地镜像添加一个包含"目标仓库地址"和"正确路径"的新别名。
- 为什么通常需要先打 Tag？
在大多数开发场景中，我们构建镜像时为了方便，往往使用简短的名称，例如：
bash
docker build -t myapp:v1 .
此时，本地镜像名为 myapp:v1。如果你想把它推送到私有仓库（如 Harbor）或 Docker Hub 的个人仓库，直接推送会失败或推错地方：
docker push myapp:v1 -> 试图推送到 docker.io/library/myapp:v1（通常权限不足或路径错误）。
为了修正这个"地址"，我们需要使用 docker tag 创建一个指向同一镜像数据、但名称符合远程仓库规范的新标签：
bash
给镜像打上包含仓库地址和目标路径的标签
docker tag myapp:v1 harbor.example.com/myproject/myapp:v1
现在推送，Docker 就知道要发给 harbor.example.com 了
docker push harbor.example.com/myproject/myapp:v1
- 什么情况下不需要单独执行 docker tag？
如果你在构建镜像时就直接指定了完整的、符合规范的镜像名称，那么就无需后续再执行 docker tag。
推荐的最佳实践（一步到位）：
bash
构建时直接指定完整的目标名称
docker build -t harbor.example.com/myproject/myapp:v1 .
直接推送，无需额外 tag
docker push harbor.example.com/myproject/myapp:v1
在这种情况下，镜像从诞生之初就拥有了正确的"快递单地址"，因此不需要后期补打标签。
- 技术细节补充
零开销操作：docker tag 不会复制镜像的数据层（Layer），它只是在本地元数据中增加了一个指针引用。因此，打标签操作瞬间完成且不占用额外磁盘空间。
多层标签：同一个镜像 ID 可以同时拥有多个标签。例如，你可以同时拥有 myapp:v1、myapp:latest 和 registry.com/proj/myapp:v1，它们都指向同一份数据。
分层上传机制：无论是否打标签，docker push 底层采用分层传输机制。它会计算每一层的哈希值，如果远程仓库已存在该层，则跳过上传，从而实现断点续传和去重，提高推送效率。
总结
必须条件：推送前，镜像名称必须包含正确的注册表地址和命名空间（对于 Docker Hub 是用户名，对于私有仓库是项目名/路径）。
常见误区：不是因为"必须 tag 才能 push"，而是因为"本地构建的简单名称不符合远程仓库的路径要求"，所以需要 tag 来重命名/别名化以匹配远程路径。
建议：在 CI/CD 流水线或脚本中，建议在 docker build 阶段直接使用 -t 参数指定完整的远程镜像名称，从而省略单独的 docker tag 步骤，使流程更简洁。