Docker Labels 应作为结构化“身份证”定义镜像元数据和生命周期信息，优先采用 org.opencontainers.image. 标准键名（如 version、created、revision、source），并扩展 com.yourcompany. 自定义标签；所有标签须由 CI/CD 自动注入，禁用手动维护；通过 docker inspect、filter、K8s 策略及镜像仓库 UI/API 实现验证与策略执行。
在 Docker 中用 Labels 为镜像添加详细元数据和版本生命周期信息，核心是把 LABEL 当作结构化“身份证”，而不是随意备注。它不改变容器行为，但能被 CI/CD、扫描工具、K8s 策略、镜像仓库（如 Harbor）直接读取和执行。
用标准键名定义基础生命周期字段
优先采用 org.opencontainers.image.* 命名空间，这是跨工具链识别的基础：
-
org.opencontainers.image.version：填语义化版本（如
1.5.2），别用latest；CI 构建时可动态注入：LABEL org.opencontainers.image.version="$(cat VERSION)" -
org.opencontainers.image.created：RFC 3339 格式时间戳，构建时生成：
LABEL org.opencontainers.image.created="$(date -u +%Y-%m-%dT%H:%M:%SZ)" -
org.opencontainers.image.revision：绑定 Git 提交哈希，确保源码可追溯：
LABEL org.opencontainers.image.revision="$(git rev-parse HEAD)" -
org.opencontainers.image.source：指向公开或内部 Git 地址，如
https://gitlab.example.com/team/app
补充业务与合规维度的自定义标签
在标准字段之外，按团队实际需要扩展，建议用 com.yourcompany.* 前缀避免冲突：
-
com.yourcompany.env：标记目标环境（
dev/staging/prod），便于部署策略拦截 -
com.yourcompany.lifecycle：显式声明阶段（
alpha/beta/ga），比 version 更直观表达成熟度 -
com.yourcompany.security.scanned：值为
true或扫描时间戳，供 OPA/Gatekeeper 校验是否通过漏洞扫描 -
com.yourcompany.owner：填写团队或负责人（如
platform-team），替代过时的maintainer
在构建流程中自动化注入，避免手动维护
Labels 不该靠人手写死，而应由构建系统实时填充：
- 在
docker build命令中用--label参数传入动态值：docker build --label "build.date=$(date -u +%Y-%m-%dT%H:%M:%SZ)" . - 在 CI 脚本里组合 Git 信息：
docker build --label "git.branch=$(git rev-parse --abbrev-ref HEAD)" --label "git.tag=$(git describe --tags --exact-match 2>/dev/null || echo 'none')" . - Dockerfile 内慎用
RUN获取时间或 Git 信息（会破坏层缓存），优先用构建参数或外部注入
验证与使用：让标签真正发挥作用
加了标签只是第一步，关键是要用起来：
- 查标签：
docker inspect --format='{{json .Config.Labels}}' myapp:1.5.2输出结构化 JSON，适合脚本解析 - 过滤镜像：
docker images --filter "label=org.opencontainers.image.version=1.5.2"或按环境筛选：docker images --filter "label=com.yourcompany.env=prod" - Kubernetes 中配合 PodSecurityPolicy 或 Kyverno 策略，拒绝运行缺少
com.yourcompany.lifecycle=ga的镜像 - Harbor 或 ECR 控制台中，这些标签会自动显示在镜像详情页，支持 UI 检索和 API 查询
