正确命名 Docker 镜像标签需明确版本、环境和来源：用语义化版本（如v1.6.0）表兼容性；加环境后缀（-dev/-staging/-prod）隔离风险；绑定Git哈希或构建ID确保可追溯；禁用latest，改用不可变滚动标签（如v1.6）。
正确命名 docker 镜像标签的核心是让每个标签能明确回答三个问题：这是哪个版本？在哪种环境用？从哪来？不靠猜、不靠查代码，一眼可知。
用语义化版本（SemVer）打基础
主版本号.次版本号.修订号（如 v1.5.3）不是形式主义，而是工程契约：
- v1.5.3 → v1.6.0：新增了功能，但老接口没删，服务升级后不会崩
- v1.6.0 → v2.0.0：改了核心逻辑，旧配置或 API 可能失效，需人工核对
- v1.6.0 → v1.6.1：只修 bug，可直接灰度替换
构建时显式指定，别省略 v 前缀，避免和纯数字标签（如 1.6.0）混淆：
加环境后缀，隔离风险
同一版本镜像在不同环境应有不同标签，而不是靠“人记住该拉哪个”，例如：
- v1.6.0-dev：供开发联调，可能含调试工具或 mock 服务
- v1.6.0-staging：对应预发环境，配置接近生产，但数据脱敏
- v1.6.0-prod：仅用于生产，经 QA 和安全扫描确认
这样部署脚本里写死 myapp:v1.6.0-prod，就不会误把测试镜像推上线。
绑定构建源头，确保可追溯
版本号管“是什么”，Git 提交哈希或构建 ID 管“从哪来”。建议至少选一种组合使用：
- v1.6.0-abc123f：哈希取前7位，短且唯一，可直接 git checkout 验证
- v1.6.0-build248：CI 流水线生成的构建序号，便于查 Jenkins/GitLab CI 日志
- 20260925-v1.6.0：日期+版本，适合内部快速定位当天发布的版本
CI 脚本中可自动注入：
GIT_SHA=$(git rev-parse --short HEAD)docker build -t myapp:v1.6.0-$GIT_SHA .
慎用 latest，禁用全局 latest
latest 不是“最新稳定版”的代名词，而是“最后一次 docker push 覆盖的任意镜像”——它没有确定性。
- 本地开发调试可用
myapp:dev-latest，但要限定命名空间，不污染主仓库 - 私有仓库中彻底禁用
myapp:latest的推送权限 - Kubernetes Deployment 中禁止出现
image: myapp:latest，CI 检查应拦截此类提交
真正需要“最新”语义时，用不可变标签替代：比如每次发布都打 v1.6（次版本滚动标签），它指向当前最新的 v1.6.x，但本身不被覆盖，只由 CI 自动更新。
