OCI 镜像规范变化会影响哪些镜像元数据

OCI 镜像规范变化主要影响清单字段、内容描述符以及关联制品的表达方式。运行配置、平台信息和注解分别存在于不同对象中；判断升级影响，要同时考虑这些对象的内容与引用，不能只比较文件系统层。

官方项目地址：https://github.com/opencontainers/image-spec

先分清规范版本与对象版本

官方发布页列有 v1.1.1 与 v1.1.0。本文采用 v1.1.0 固定版本的字段定义解释 1.1 系列的元数据模型，不把既有字段描述成刚发布的新功能，也不推断具体仓库或运行时已经全面实现这些能力。

规范版本与 schemaVersion 不是同一套编号。该版本的 Image Manifest 使用 schemaVersion: 2，采用 1.1 系列并不意味着把字段改为 1.1。mediaType 表达对象格式，artifactType 表达制品类别，也不能互相替代。

理解变化时，先记录构建器产生哪些对象，再看仓库保存哪些对象，最后看复制工具带走哪些对象。“支持 OCI”这个笼统描述，不足以说明所有元数据都能完整往返。

清单、配置和描述符各管什么

Config 中的 Labels 与 Manifest 中的 annotations 位于不同 JSON 对象。即使显示界面统称它们为“标签”，读取路径仍不同。注解不自动变成环境变量，也不意味着容器内程序可以直接读取。

配置里的创建时间、作者、入口参数，与文件系统层的数据不是同一个层面。只修改配置时，层可以复用，但配置身份及引用它的清单可能改变。因此，“层没有变化”不能直接推出“镜像摘要没有变化”。

Descriptor 的 digest 标识目标内容，size 表示目标内容的字节长度。若复制或转换实际改变了内容，就不能简单沿用旧描述符。反过来，修改外层对象也不必然改变每个底层 blob，应按变化发生的位置追踪引用。

subject 怎样连接关联制品

1.1 模型中的 artifactType 用于表达制品类别，可选的 subject 描述符用于关联另一份清单。SBOM、签名等附属对象可以用这类关系表达，但具体格式和信任判断仍由相应工具及规范决定。存在 subject，不代表关联内容已经可信。

镜像可拉取而附属材料不可发现时，应分别观察对象是否存在、subject 是否指向目标摘要，以及仓库提供何种发现接口。Referrers 涉及分发规范和实现，不能仅凭 Image Specification 定义了字段，就判断某个仓库具备对应接口。

建议发布记录同时保存主镜像摘要、关联对象摘要和产生它们的工具版本。只保存可变 tag，在它指向另一份清单之后就难以还原原来的关联目标。对象发生转换后，签名是否仍适用，要根据签名系统规则处理。

复制与清理不能只看镜像层

元数据的生命周期可以按产生、存储、复制、检索和清理组织。构建端记录输出对象；存储端明确保留范围；复制端说明是否包含附属制品；消费端区分平台选择、配置解析与制品发现。这些是不同能力，不能用一次容器启动成功替代全部判断。

Annotations 是字符串到字符串的映射，消费者不应因为不认识某个键而报错。自定义键宜使用自己的反向域名命名空间，避免占用 OCI 保留前缀。source、revision、version 等信息适合检索追溯，但不能代替摘要作为内容身份。

清理策略还应考虑关联制品的保留需求。垃圾回收和恢复行为取决于实际仓库实现，不能单凭 subject 推导“删掉镜像就一定删掉签名”或“签名一定永久保留”。先确定需要保留的对象集合，再安排清理。

只改 annotations，就必须重建全部层吗？

不必以重建层为前提。变化所在对象及相关引用需要更新，层是否重建取决于实际内容和工具行为。

schemaVersion 为 2，说明它不支持 OCI 1.1 吗？

不能。要看字段、对象格式和工具能力，不能混用规范版本与清单编号。

Labels 能代替所有 annotations 吗？

不能。对象位置与消费方式不同，应根据运行配置或元数据检索需求选择。

官方发布记录：https://github.com/opencontainers/image-spec/releases

字段参考：https://github.com/opencontainers/image-spec/tree/v1.1.0