关键在于理清“先有镜像、再打标签、最后登录上传”逻辑链：docker tag为镜像添加含仓库地址和语义化版本的正式名称（如registry.cn-hangzhou.aliyuncs.com/myteam/myapp:v1.2.0），不复制内容；docker login针对具体仓库地址认证；docker push必须使用tag生成的完整名称，三步缺一不可。
要用好 Docker 镜像标记和推送，关键不是记住命令顺序，而是理清“先有镜像、再打标签、最后登录上传”这个逻辑链。本地没镜像，或标签格式不对，push 肯定失败；没登录，权限就卡在第一步。
镜像标记：让镜像带上仓库地址和版本号
标记（docker tag）本质是给镜像“起一个带地址的正式名字”，不是复制也不是重命名。它不改变镜像内容，只新增一条指向它的引用。
- 基本格式：docker tag 源镜像名[:标签] 目标仓库地址/命名空间/镜像名[:新标签]
- 比如把本地构建的
myapp:dev推到阿里云杭州区域私有仓库：docker tag myapp:dev registry.cn-hangzhou.aliyuncs.com/myteam/myapp:v1.2.0 - 如果源镜像没标签，默认是
latest；目标标签省略时也默认为latest - 推荐用语义化版本（如
v1.2.0）或 Git 提交短哈希（如git-abc123），避免单独依赖latest
登录镜像仓库：确认身份才能上传
登录（docker login）是针对具体仓库地址的操作，不是全局一次登录永久有效。
- 推送到 Docker Hub：
docker login（回车后输入账号密码） - 推送到私有仓库（如 Harbor 或阿里云 ACR）：
docker login registry.example.com或docker login registry.cn-hangzhou.aliyuncs.com - 登录成功后，凭证会存到
~/.docker/config.json，后续 push 才能通过认证 - 使用子账号 AccessKey 登录私有云仓库更安全，避免主账号密钥泄露
推送镜像：把标记好的镜像发到远程仓库
推送（docker push）操作的对象，必须是之前用 docker tag 明确生成的那个完整名称。
- 命令格式：docker push 仓库地址/命名空间/镜像名:标签
- 继续上面的例子：
docker push registry.cn-hangzhou.aliyuncs.com/myteam/myapp:v1.2.0 - 不能写成
docker push myapp:v1.2.0—— 这会默认推到 Docker Hub，且镜像名不匹配 - 推送过程是分层上传，网络中断可断点续传；大镜像建议启用并行上传（需仓库支持）
常见问题怎么快速排查
推送失败通常就三类原因，按顺序检查效率最高：
-
找不到镜像：运行
docker images确认列表里有你 push 命令里写的那个全名（含仓库地址） -
认证失败：执行
docker login 仓库地址再试；检查 config.json 是否包含对应 registry 的 auth 记录 - 权限不足：确认账号对目标命名空间有 push 权限；私有仓库管理员需提前分配角色（如 Harbor 的 project member）
