核心是避免同名tag指向不同镜像ID，必须坚持语义化版本号（如v1.2.3）作为生产唯一标识，禁止覆盖已有tag、禁用latest、导入离线镜像时需主动清理冲突tag并核验绑定。
核心是避免同名 tag 指向不同镜像 ID，关键在于不复用、不覆盖、不依赖模糊标签。
坚持语义化版本号作为主标签
使用 v1.2.3 这类明确的语义化版本号（SemVer）作为生产唯一标识。每次功能变更、修复或兼容性升级，都生成新版本号，而不是反复打 latest 或 prod。这样每个 tag 天然唯一，系统不会尝试覆盖已有 tag，而是新增绑定。
- v1.2.3 → 正式发布，只构建一次，只推送一次
- v1.2.4 → 下一个修复版本，与 v1.2.3 完全独立
- 禁止将 v1.2.3 改为 v1.2.4 后再用相同命令重新打标推送
禁止在生产流程中使用 latest 标签
latest 是动态标签，没有固定指向。CI/CD 流水线若持续向它推送，会导致旧镜像失去可访问入口，新部署可能拉到非预期内容。生产环境部署指令必须显式指定带版本号的 tag，例如 myapp:v1.2.3，而非 myapp:latest。
- 开发测试可用
latest，但仅限本地或 CI 构建临时验证 - 镜像仓库策略可配置为拒绝覆盖已存在 tag（如 Harbor 的“不可变 tag”规则）
- Kubernetes Deployment 中 image 字段必须写死版本号，禁用 :latest
导入离线镜像时主动清理冲突 tag
离线环境用 docker load -i xxx.tar 导入时，若 tar 包内含 nginx:v1.23，而本地已有同名 tag 指向旧镜像，新镜像会变成 <none>:<none></none></none> —— 看似导入成功，实则 tag 未生效。
- 导入前先运行
docker images nginx:v1.23确认是否已存在 - 存在则用
docker rmi nginx:v1.23删除原 tag（不影响其他 tag 指向的同一镜像） - 导入后立即执行
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}" | grep nginx，核对 tag 是否绑定到新镜像 ID - 若未绑定，用
docker tag <new-id> nginx:v1.23</new-id>手动重打
用 Git 提交哈希补充可追溯性，不替代版本号
在主版本号基础上附加构建上下文，例如 v1.2.3-gitabc123，既保留语义化主干，又锁定代码快照。这类标签用于调试和审计，不参与部署决策；生产部署仍以 v1.2.3 为准。
- CI 脚本中自动生成：
docker build -t myapp:v1.2.3-git$(git rev-parse --short HEAD) . - 同一版本号下多个 git 哈希，说明存在多轮构建或分支差异，便于快速定位问题源头
- 避免单独用
git-abc123作为生产标签，它不具备版本演进含义
