必须禁用 latest 标签上生产，因其是可变指针而非稳定版本；应使用语义化版本（如v1.4.2）或镜像摘要（@sha256:...），并配置registry不可覆盖策略、定期清理悬空镜像。

别用 latest 标签上生产，这是最核心的避坑前提。它不是“最新稳定版”，而是“随时可能变”的指针，会直接破坏部署一致性、回滚能力和故障复现能力。

陷阱一：latest 标签导致环境漂移与不可重现部署

同一个 nginx:latest 在不同时间、不同节点拉取，可能对应完全不同的镜像摘要（SHA）。开发机器构建时用的是某次 CI 推送的 latest，而生产集群拉取时，仓库里 latest 已被覆盖为另一个版本——代码、依赖、安全补丁全都不一样。

• CI/CD 流水线无法审计“这次上线到底发了什么”
• Kubernetes Deployment 更新后行为异常，却无法在本地复现
• 线上出问题想回滚，但连“上一版是什么标签”都查不到

陷阱二：标签命名混乱引发协作与运维混乱

团队中出现 v1、prod、20251009、final-fix 等随意标签，本质是放弃版本语义。没人知道哪个该上生产，哪个只是临时测试，哪个已废弃但还在被调用。

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

• 推荐统一采用语义化版本 + 环境前缀或后缀，例如：myapp:v1.4.2、myapp:staging-v1.4.2、myapp:v1.4.2-git-abc123f
• 禁止使用下划线、大写字母、空格；只用小写字母、数字和短横线（-）
• 在 CI 脚本中自动生成标签，避免人工打标出错

陷阱三：忽略镜像不可变性与标签覆盖风险

很多私有 Registry 默认允许覆盖同名标签（如重复推送 myapp:v1.2.0）。这会让“v1.2.0”失去唯一性——今天指向安全修复版，明天被替换成含漏洞的调试版，而所有引用它的 YAML 或脚本毫无感知。

• 务必在 Registry 层启用 标签不可覆盖策略（如 Harbor 的 “Immutable Tag” 规则）
• 生产环境优先使用镜像摘要（myapp@sha256:xyz...），它永远不变
• 在 Dockerfile 中也避免写 FROM alpine:latest，改用 FROM alpine:3.20 或具体 SHA

陷阱四：删除标签≠删除镜像，空间与安全隐患并存

docker rmi myapp:latest 只删掉这个标签引用，只要还有其他标签（比如 myapp:v1.4.2）或容器在运行，底层镜像层就仍驻留磁盘。长期积累大量“无名”或“过期”镜像，既浪费存储，又增加扫描盲区。

• 先用 docker images --digests 查看哪些镜像 ID 被多个标签共用
• 确认无容器引用后，用 docker image prune -a 清理未被任何标签引用的悬空镜像
• 定期通过 Registry API 或平台工具（如 Harbor GC）清理旧标签及对应 manifest

本质上，Docker 标签不是版本号，而是可变别名。真正稳定的锚点只有镜像摘要（SHA）和受控的语义化标签。把标签当版本用，就等于把指针当数据用——看似省事，实则埋雷。