调用Docker仓库API需遵循Registry HTTP API v2协议，正确处理Bearer令牌认证、指定Accept头（如OCI用application/vnd.oci.image.manifest.v1+json）、区分tag与digest操作、解析manifest中config.digest和layers等元数据。
调用 Docker 仓库 API 获取和管理镜像元数据，核心在于理解 Registry HTTP API v2 协议、正确处理认证、解析响应结构，并安全操作标签、清单（manifest）与层（layer）信息。
获取镜像清单（Manifest）需指定 MediaType 和 Accept 头
拉取镜像元数据时，不能仅靠 GET /v2/<name>/manifests/<reference> 就完事。Registry 要求客户端明确声明期望的清单格式，否则可能返回 406 Not Acceptable 错误。
- 对 OCI 镜像，请求头必须包含：
Accept: application/vnd.oci.image.manifest.v1+json - 对 Docker 镜像（较旧），使用：
Accept: application/vnd.docker.distribution.manifest.v2+json - 若不确定类型，可同时提供多个 Accept 值（用逗号分隔），Registry 会返回首个匹配格式
- 参考命令示例：
curl -H "Accept: application/vnd.oci.image.manifest.v1+json" \<br> -H "Authorization: Bearer $TOKEN" \<br> https://registry.example.com/v2/myapp/manifests/latest
认证流程依赖令牌（Bearer Token）而非基础认证
公有或私有 Registry（如 Harbor、ECR、GCR）通常不接受直接的 Basic Auth。实际流程是：先触发未授权访问 → 解析 WWW-Authenticate 响应头 → 向 auth 服务申请令牌 → 携带令牌重发请求。
- 首次请求 manifest 返回 401 时，检查响应头：
WWW-Authenticate: Bearer realm="https://auth.example.com/token",service="registry.example.com",scope="repository:myapp:pull" - 提取 realm、service、scope，向 realm 地址发起 GET 请求，附上 service 和 scope 参数
- 从返回的 JSON 中提取
token字段，用于后续所有受保护接口的Authorization: Bearer <token> - 注意：Token 有时效性（通常数分钟），需缓存并刷新机制支持长期调用
镜像标签（Tag）与摘要（Digest）需区分管理
Tag 是可变别名，Digest 是不可变内容指纹。API 层面二者行为差异显著：
-
列出所有 Tag：调用
GET /v2/<name>/tags/list（需额外开启 catalog 或 tag listing 支持，部分 Registry 默认禁用） -
删除 Tag：Docker Registry v2 不提供直接删除 Tag 的 API；实际需先获取该 Tag 对应的 manifest digest，再 DELETE
/v2/<name>/manifests/<digest>（这会移除该 digest 关联的所有 tag，除非其他 tag 仍指向它） -
安全绑定 Tag 到 Digest：推送镜像时用 digest 推送（如
docker push registry/repo@sha256:abc...），或推送后立即通过 manifest 查询确认其 digest，避免 tag 被覆盖导致元数据漂移
解析 Manifest 内容以提取关键元数据
成功获取 manifest 后，JSON 主体包含镜像结构的核心线索，重点关注以下字段：
-
config.digest：指向 config blob 的 SHA256，GET/v2/<name>/blobs/<digest>可获得容器配置（含 OS、入口点、环境变量等） -
layers[]中每个对象含digest和size，可用于计算镜像总大小、校验层完整性或分析层复用情况 -
annotations（OCI）或labels（Docker config）常存放构建信息（如org.opencontainers.image.source、org.opencontainers.image.version），是自动化溯源的关键依据 - 注意：manifest 可能是
application/vnd.docker.distribution.manifest.list.v2+json（多架构清单），此时需递归解析manifests[]中各平台对应的子 manifest
不复杂但容易忽略细节——认证流、Accept 头、digest 绑定和 manifest 嵌套结构，是稳定对接任何符合规范 Registry 的基础。
