标签不可变策略是什么
在仓库开启标签不可变（ECR 的 tag immutability、Harbor 标签不可变规则等）：从制度层面阻止同标签覆盖重推，保证「某标签指向的内容永远一致」。这是可回滚与可追溯的前提——回滚引用旧标签时，内容不会被悄悄替换成别的构建。它不改变权限模型，只堵住覆盖这条路；删除与保留仍由权限与清理策略管理。
基本信息
| 平台 | ECR 支持 tag immutability；Harbor 有标签不可变规则 |
|---|---|
| 效果 | 同 tag 重推直接失败或被拒绝 |
| 配合 | 发布流程改用新版本号 + 新标签 |
| 特例 | 滚动标签（stable/latest）需明确其可变语义 |
| 启用节奏 | 先在试点仓库验证老流程兼容性再推广 |
典型使用场景
- 生产镜像仓库：防止同标签被覆盖
- 合规审计：引用某标签可证明当时内容
- 可信回滚：旧标签内容与当时完全一致
- 多团队共享仓库：防止他人误重推覆盖
- 滚动交付：stable 滚动标签 + 不可变版本标签组合
- 验收标准：交付说明里以不可变版本标签为准，沉淀成发布规范，供审计引用
影响与替代
影响与替代
开启后：
- 修 bug → 发新版本（1.8.1），不重推 1.8.0
- 需要移动指针 → 用单独的滚动标签（如 stable）并明确其可变语义
- 老流程若依赖重推：先改发布脚本再切换，否则流水线直接失败平台对照
| 平台 | 机制 | 注意 |
|---|---|---|
| ECR | tag immutability 开关 | 按仓库粒度设置 |
| Harbor | 标签不可变规则 | 项目级配置 |
| Docker registry | 无内建开关 | 靠流程与清理策略约束 |
不可变是「可回滚」的前提：回滚引用旧标签能确保内容一致。
小步启用：先从生产仓库试点，跑完一个发布周期确认流程顺畅再推广，转换期保留回退方案，出现阻断再回退不丢人。