企业级 Docker 镜像 Tag 应以语义化版本（如 v1.2.0、v2.0.0）为主干，辅以架构/环境等可解析短横标识（如 v1.2.0-amd64、v1.2.0-prod），禁用模糊标签（dev/test），严禁覆盖已发布 Tag，缺陷修复须升修订号（v1.2.1）而非重推。
用好 Docker 镜像 Tag 是企业级研发流水线稳定运行的基础。关键不是堆砌信息，而是让每个 Tag 能被人读懂、被机器识别、被流程自动分发和校验。
语义化版本为主干，明确表达变更意图
对外发布或需长期维护的镜像（如基础组件、网关、核心服务），必须使用 vX.Y.Z 格式打标，例如 v1.2.0、v2.0.0：
- v1.2.0 → 主版本 1，次版本 2，修订 0；表示向后兼容的功能新增
- v2.0.0 → 主版本升级，含不兼容变更，必须同步更新文档与升级说明
- 禁止混用前缀如
release-v1.2.0，除非 CI/CD 全链路支持解析该前缀
环境与上下文标识为补充，不替代版本号
同一语义版本可能适配不同平台或用途，可用短横分隔追加标识，保持可读且可解析：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
-
v1.2.0-amd64、v1.2.0-arm64—— 明确 CPU 架构 -
v1.2.0-alpine、v1.2.0-ubuntu22.04—— 区分基础发行版 -
v1.2.0-prod、v1.2.0-staging—— 明确部署目标环境 - 避免过度组合，如
v1.2.0-alpine-arm64-debug-glibc，应通过 manifest list 或多阶段构建解耦
开发与测试阶段用可追溯但非生产标签
未进入正式发布流程的镜像，需能快速定位来源，但严禁在生产配置中引用：
-
feat/auth-abc123—— 分支名 + 提交简写，用于功能验证 -
main-20260428—— main 分支每日构建，日期统一为 YYYYMMDD -
sha-xyz789-ci—— CI 流水线生成的唯一构建标识 - 禁用模糊词单独作 tag：如
dev、test、new，无法回溯源头
强制不可变性，杜绝覆盖已发布 Tag
Tag 是指向镜像 ID 的指针，内容必须恒定。覆盖行为会破坏可重现性：
- CI 脚本中需显式校验：
docker pull $IMAGE:$TAG失败才允许构建推送 - 发现 v1.2.0 存在严重缺陷？发布
v1.2.1，而非重推v1.2.0 - 定期归档旧版本：保留最近 3 个主版本（v1.x、v2.x、v3.x）的全部次版本，更早版本移入
archive/命名空间或离线存储
