镜像标签引用计数并非 Docker 原生功能，主流仓库不维护实时使用计数；需通过扫描 Kubernetes、CI/CD 配置、Git 仓库等可信源生成活跃标签清单，再与 Registry 标签列表比对识别可清理镜像，并配合语义化标签与自动生命周期策略实现安全治理。
镜像标签的引用计数本身不是 Docker 原生支持的功能，Docker Registry 协议（v2）和主流镜像仓库（如 Harbor、Docker Hub、ECR、ACR、Nexus Repository）默认不维护“某个 tag 被多少个地方拉取/使用”的实时计数。所谓“通过标签引用计数管理镜像”，实际是借助外部可观测性手段或仓库高级功能实现的近似策略，核心目标是：安全清理未被使用的旧镜像，避免误删仍在运行或被 CI/CD 引用的镜像。
理解“引用”在镜像生命周期中的真实含义
一个 tag（如 app:v1.2.0）是否“被引用”，取决于它是否仍被以下任一场景显式依赖：
- Kubernetes Deployment / StatefulSet / CronJob 的
image:字段； - CI/CD 流水线脚本（如 GitHub Actions、GitLab CI）中
docker pull或部署命令指定的镜像； - 本地开发环境或测试集群中正在运行的容器（
docker ps --format '{{.Image}}'）； - 其他镜像的
FROM指令（多阶段构建中作为 base 镜像）； - 配置中心、IaC 模板（Terraform、Ansible）中硬编码的镜像路径。
这些引用关系分散在不同系统中，Registry 自身无法自动感知——它只负责存储和分发，不追踪下游消费行为。
利用仓库自带的使用统计（有限但可用）
部分企业级仓库提供基础的拉取日志或访问审计能力，可间接反映活跃度：
-
Harbor：开启审计日志后，可通过
/api/v2.0/audit-logs查询PULL_IMAGE记录，按 tag 统计最近 7/30 天拉取次数；需配合定时任务聚合分析； -
AWS ECR：集成 CloudTrail，筛选
BatchGetImage和GetDownloadUrlForLayer事件，提取imageTag字段做频次统计； -
Azure ACR：启用诊断设置，将日志导出到 Log Analytics，查询
AcrPull表中imageName和tag字段； - Docker Hub（免费版）：不提供拉取日志；付费团队版可通过 API 获取有限的镜像活动摘要（非 per-tag 计数）。
⚠️ 注意：拉取次数 ≠ 实际依赖。一次 CI 构建可能拉取多次，而生产环境长期运行的 Pod 可能数月不拉取新镜像，但 tag 仍必须保留。
构建轻量级引用发现机制（推荐落地方式）
更可靠的做法是主动扫描可信源，生成“已知引用清单”，再与 Registry 中的 tag 做差集：
- 用
kubectl get all -A -o jsonpath='{..image}' | sort -u提取集群内所有 Pod、Job 等资源使用的完整镜像名（含 tag）； - 扫描 Git 仓库（如所有 Helm Chart values.yaml、Kustomize kustomization.yaml、GitHub Actions YAML），用正则匹配
image:.*:[^@:\s]+提取 tag； - 结合 CI/CD 平台 API（如 GitLab
/projects/:id/pipelines）获取最近成功流水线中使用的镜像； - 将上述结果去重合并为
active-tags.txt，再调用 Registry API（GET /v2/<repo>/tags/list</repo>）获取全部 tag，找出不在清单中的 tag —— 这些即为候选清理对象。
该方法无需修改现有流程，只需定期（如每天凌晨）执行脚本，输出待清理报告供人工确认或自动触发 DELETE（需开启 Registry 删除权限）。
配合语义化标签与生命周期策略（治本之策）
减少对“引用计数”的强依赖，从源头降低管理复杂度：
- 禁止使用
latest，强制采用语义化版本（v1.2.0）+ Git commit SHA（v1.2.0-abc123）双标签； - 为每个发布分支（
release/v1.2）打release-v1.2标签，并设置保留策略（如“保留最近 3 个 release-* tag”）； - CI 构建时自动添加
build-time标签（如20240520-1423-abc123），并配置仓库策略：自动删除 30 天前的 build-time tag； - 在镜像元数据中写入
org.opencontainers.image.source和org.opencontainers.image.revision，便于反向追溯引用来源。
这些实践让镜像生命周期变得可预测，比依赖动态计数更稳定、易审计。
不复杂但容易忽略：真正的引用管理，不在 Registry 里，而在你的 Git 仓库、K8s 清单和 CI 配置中。把它们当“镜像消费账本”来维护，比等待一个不存在的全局计数器更有效。
