Docker build时添加Labels必须在构建阶段写入，可通过--label参数（支持多次或--label-file）、Dockerfile中LABEL指令实现；docker tag无法补加Labels，因其仅创建别名而不修改镜像内容。
docker build 时怎么加 Labels
Labels 是镜像元数据，不是运行时配置，必须在构建阶段写入。用 --label 参数最直接，支持多次出现，也支持从文件读取：
docker build -t myapp:v1.2.0 --label "env=prod" --label "team=backend" .- 把标签写进
labels.txt（每行一个key=value），再用--label-file labels.txt - 在
Dockerfile中用LABEL指令：比如LABEL org.opencontainers.image.version="v1.2.0"，它会在构建时固化进镜像层
注意：LABEL 指令写在 Dockerfile 末尾也没用——它只影响当前及之后的层；如果中间某层被缓存，旧 LABEL 仍会保留。所以推荐统一用 docker build --label 控制，避免意外继承。
docker tag 能不能补加 Labels
不能。docker tag 只是给已有镜像添加新别名，不修改镜像内容，更不会写入 Labels。你执行：
docker tag myapp:v1.2.0 myapp:staging docker inspect myapp:staging | grep Labels
输出的 Labels 和 myapp:v1.2.0 完全一致——没新增、没覆盖、没清空。
想改 Labels？只能重新构建，或用 docker commit（不推荐）：先运行容器，docker exec 里改配置，再 docker commit -c 'LABEL team=frontend' <container-id> newimg。但这样破坏了不可变性，且 Labels 不是设计用来运行时动态管理的。
怎么查 Labels 并用于运维筛选
Labels 存在镜像配置里，用 docker inspect 查，但默认输出太长。推荐用 --format 提取关键字段：
- 查所有带
env=prod的本地镜像：docker images --format "{{.Repository}}:{{.Tag}} {{.ID}}" | xargs -n2 sh -c 'docker inspect -f "{{.Config.Labels.env}}" $0 2>/dev/null | grep -q "prod" && echo $0' - 批量导出 Labels 到 CSV：
docker images --format "{{.ID}}" | xargs -I{} docker inspect -f '{{.ID}},{{.Config.Labels."team"}},{{.Config.Labels."env"}}' {} - CI/CD 中做准入检查：脚本里用
docker inspect -f '{{index .Config.Labels "critical"}}' myapp:latest判断是否标记为高危组件
注意：docker images 命令本身不显示 Labels，必须靠 inspect；而且远程仓库（如 Harbor）的 Labels 默认不暴露给 pull 用户，除非你启用了元数据同步策略。
Labels 和 Tag 的分工容易混淆
Tag 是“怎么叫它”，Labels 是“它是什么”。比如：
-
nginx:1.25.3—— Tag 表达版本，用于拉取和推送 -
LABEL org.opencontainers.image.source="https://git.example.com/app/nginx"—— Labels 记录来源，供审计工具扫描 -
LABEL com.example.team="infra"—— Labels 标记归属，配合 KubernetesimagePullSecrets权限隔离
生产环境常见错误是把环境信息全塞进 Tag（如 myapp:prod-v1.2.0），结果导致镜像仓库里一堆重复镜像。正确做法是固定 Tag（如 v1.2.0），用 Labels 区分部署属性，再由部署工具（Argo CD / Flux）按 Labels 自动匹配策略。
Labels 的键名没有强制规范，但建议遵循 OCI Annotations 标准，否则某些镜像扫描器或策略引擎可能忽略自定义 key。
