核心是让每个Tag指向唯一、不可变的镜像摘要，杜绝“同名不同镜”现象；强制语义化版本号（如v1.2.3）作为生产唯一标识，禁用latest，启用仓库不可变策略，离线导入时主动清理冲突Tag，并优先使用镜像digest部署。
核心是让每个 Tag 指向唯一、不可变的镜像摘要，杜绝“同名不同镜”现象。关键不在于事后追查，而在于从构建、推送、存储到拉取的全链路设防。
强制使用语义化版本号作为生产唯一标识
所有生产镜像必须打上形如 v1.2.3 的语义化标签，且该标签只生成一次、只推送一次。v1.2.3 不得被重新打标指向另一个镜像 ID，也不得在后续构建中被覆盖重用。
- CI/CD 流水线中加入标签格式校验脚本：匹配
^v[0-9]+\.[0-9]+\.[0-9]+$，不合规则中断构建 - 禁止将 Git tag v1.2.3 对应的镜像构建后，再用相同命令反复推送——每次发布都应触发新版本号（如 v1.2.4）
- 部署清单（Kubernetes YAML、docker-compose.yml）中 image 字段必须写死
myapp:v1.2.3，禁用:latest或模糊别名
在镜像仓库启用不可变 Tag 策略
仅靠规范无法杜绝人为误操作，必须依赖仓库级技术约束。以 Harbor 为例，这是最直接有效的防线：
- 为 prod 项目开启“不可变 Artifact”策略，配置规则：拒绝覆盖已存在的
^v[0-9]+\.[0-9]+\.[0-9]+$标签 - 同时拦截
^latest$和^prod$类动态标签的推送请求，防止其成为覆盖入口 - 若使用 Nexus 或自建 Registry，可通过 webhook + 自定义拦截器或定时 API 校验实现等效控制
离线导入时主动识别并清理冲突 Tag
在 air-gapped 环境中，docker load -i 容易导致本地已有同名 Tag 绑定旧镜像，新镜像变成
- 导入前执行
docker images myapp:v1.2.3，确认是否已存在 - 存在则先运行
docker rmi myapp:v1.2.3（仅删除标签，不影响其他 Tag 共享的底层镜像） - 导入后立即核验：
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}" | grep myapp:v1.2.3 - 若未绑定新 ID，手动执行
docker tagmyapp:v1.2.3
生产部署优先使用镜像 digest 而非 Tag
Tag 是可变指针，digest（如 sha256:abc...）才是镜像唯一指纹。彻底规避覆盖风险的终极手段是绕过 Tag：
- CI 流程在成功推送后，自动记录并输出完整 digest 地址，例如：
registry.example.com/myapp:v1.2.3@sha256:abcd123... - Kubernetes Deployment 中 image 字段直接填写带 digest 的完整标识，而非仅写
myapp:v1.2.3 - 配合 Docker Content Trust（Notary），要求集群只接受已签名且 digest 可验证的镜像
