LABEL指令是Docker镜像元数据管理最规范方式，必填字段包括maintainer、description、version、build-date；扩展字段推荐org.opencontainers.image.source、revision、contact、license；需避免重复键、未引号包裹空格值、存储敏感信息或动态状态。
直接用 Dockerfile 的 LABEL 指令写入元数据，是最规范、可复用、可追踪的方式。它不依赖图形界面或运行时手动添加，构建即固化，适合 CI/CD 和团队协作。
LABEL 指令的必填核心字段
每个镜像都应包含以下基础元数据，便于识别与维护：
-
maintainer：记录责任人邮箱（如
LABEL maintainer="ops@team.example"），避免用姓名——邮箱更稳定、可联系 -
description：一句话说明用途（如
LABEL description="生产环境订单处理 API 服务"），不写“微服务”“高可用”这类空泛词 -
version：绑定语义化版本（如
LABEL version="2.3.1"），建议与 Git tag 或发布流程联动，不要写latest或dev -
build-date：用构建时自动注入（如
LABEL build-date="${BUILD_DATE}"），配合docker build --build-arg BUILD_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ)实现时间戳固化
扩展元数据提升可运维性
除基础字段外，加入这些标签能显著降低排查和交接成本：
-
org.opencontainers.image.source：指向 Git 仓库地址（如
LABEL org.opencontainers.image.source="https://git.example.com/team/app"），符合 OCI 标准，Kitematic 和多数镜像扫描工具可识别 -
org.opencontainers.image.revision：填入 Git commit SHA（可通过
--build-arg注入），确保镜像与代码精确对应 -
contact：明确支持渠道（如
LABEL contact="slack:#backend-support, pagerduty:prod-api"），比邮箱更适配现代运维流程 -
license：注明许可证类型（如
LABEL license="Apache-2.0"），尤其在合规审计中不可省略
避免常见陷阱
看似简单，但 LABEL 容易误用导致信息失效或冲突：
- 不要在多个 LABEL 行重复定义同一键（如两次写
LABEL version=...），后写者会覆盖前者 - 值中含空格或特殊字符时，必须用双引号包裹（
LABEL description="API for /v2/orders endpoint"） - 敏感信息（如密钥、内部 URL）绝不可写进 LABEL——它随镜像分发且无法加密，应通过环境变量或 secret 管理
- 不推荐用 LABEL 存储动态状态（如 “last-updated-by” 或 “deploy-env”），这类信息应在部署层（如 Helm values 或 docker-compose.yml）注入
验证与查看方法
构建完成后，用命令快速确认元数据是否生效：
- 查镜像 LABEL：
docker inspect --format='{{json .Config.Labels}}' your-image:tag - 查容器 LABEL（继承自镜像）：
docker inspect -f '{{.Config.Labels}}' container-name - Kitematic 中打开容器 → “详情”页 → 向下滚动即可看到全部 LABEL 键值对
