标签与摘要的区别
标签是人读的别名，摘要（digest）才是镜像的唯一标识。生产环境应使用不可变标签（语义版本或 git commit），latest 只留给本地便利场景：它没有版本语义，谁最后推谁赢，回滚与审计都会失效。多个标签可以指向同一个摘要，例如 v1.2.3 与 stable 同时指向同一镜像，这样既能锁版本又便于人工识别。
基本信息
| 推荐形式 | app:1.2.3（语义版本）、app:git-9f3c1ab（可溯源到提交） |
|---|---|
| latest 的陷阱 | 无版本语义，指向最后一次推送结果，无法锁定与回滚 |
| 多标签 | 同一镜像可同时打 v1.2.3 与 stable，二者指向同一摘要 |
| 校验摘要 | docker inspect --format '{{index .RepoDigests 0}}' 取实际摘要 |
| 不可变标签 | 仓库侧开启标签不可变规则，从根本上禁止同名覆盖推送 |
| 拉取策略 | Kubernetes 中标签为 latest 时默认 imagePullPolicy 为 Always，会被反复拉取 |
典型使用场景
- 生产部署锁定版本，回滚时能确定拉取的是哪个镜像
- 多环境晋级：dev 到预发再到生产使用同一摘要，避免「测试过的不是上线的那份」
- 故障追溯：从运行中的镜像反查到具体的代码提交
- CI 产出双标签：语义版本用于对外，commit 哈希用于内部排查
- 本地开发用 latest 快速迭代，但绝不进入部署清单
打标签与核对
打标签与核对
docker tag app:build-2026 app:1.2.3 # 由构建产物生成版本标签
docker push registry.example.com/team/app:1.2.3 # 推送到仓库
docker inspect registry.example.com/team/app:1.2.3 \
--format '{{index .RepoDigests 0}}' # 取实际摘要，写入部署清单
docker pull registry.example.com/team/app@sha256:abc... # 用摘要拉取，绝对锁定内容
kubectl set image deploy/app app=registry.example.com/team/app:1.2.3 # 部署指定版本标签形式与适用场景
| 标签形式 | 可变性 | 适用场景 | 风险 |
|---|---|---|---|
| 语义版本 1.2.3 | 靠仓库规则保证不可变 | 生产部署与回滚 | 被覆盖推送后失去意义，需开启不可变规则 |
| git 提交 git-9f3c1ab | 不可变 | 溯源与灰度验证 | 短哈希需维护到分支与构建记录的映射 |
| 环境名 stable / prod | 可变，指向当前稳定版 | 人工识别当前版本 | 回滚时无法知道当时指向哪个镜像 |
| latest | 可变 | 本地试用与快速演示 | 生产禁用，无版本语义且拉取行为不可控 |
部署清单里记录摘要而非标签：回滚时用摘要拉取，保证与上线镜像完全一致。标签可以作为可读补充，但判定「跑的是哪份镜像」要以摘要为准。
同名标签覆盖推送会让引用该标签的环境静默变化：正在运行的节点缓存、其他团队已部署的清单，都会在下次拉取时拿到不同内容，且没有任何配置变更记录可供追查。