Cloud Product Registry正式可用：云产品目录有了API，重分类关系可追踪
2026年9月28日，Google Cloud宣布Cloud Product Registry API正式可用（GA）。它将第一方云产品的官方层级开放为可编程数据，供内部目录与治理工具读取。对于长期用表格维护产品名称、别名和所属系列的团队，新入口提供了一个更清晰的对照来源：目录中的名称与分类可以回到官方记录核验。
配图为AI生成的概念插图，表现产品目录的层级关系，不是真实产品界面。
套件、产品与变体，表达不同层次
官方数据模型有三个层次：Product Suite、Logical Product和Logical Product Variant。套件代表统一品牌下的产品集合，逻辑产品是独立提供的方案，变体则针对特定技术或使用场景做专门化。例如Cloud SQL可作为产品，Cloud SQL for MySQL与Cloud SQL for PostgreSQL是不同变体。
这种模型有助于解决内部目录常见的粒度混乱。同一份清单里若同时出现平台总称、数据库产品与具体数据库引擎，而没有声明层级，统计就容易重复。目录层级明确之后，团队可以决定是在产品层分配责任，还是在变体层记录兼容性，而不是让名称格式偶然决定管理方式。
但官方概览对本次范围有明确限制：只包含核心Google Cloud产品，不包含Google Maps和Google Workspace产品。文档用这些名称解释套件概念，不表示API已经覆盖它们。构建企业全产品目录时，需要标记覆盖边界，并为其他来源保留独立入口。
产品元数据，不是用户已部署资源的清单
当前API提供名称、官方标题及生命周期阶段等基础元数据。它描述产品本身及层级关系，不会因为某个产品出现在目录里，就证明某个项目已经启用、部署或购买了它。
这一点决定了合理用法。内部资产系统可以把发现的资源类型映射到官方产品，再附上本组织的负责人、项目、成本与合规信息；账单系统也可以借助映射改善展示。但映射之外的实际用量、授权和资源状态，仍应来自各自的权威系统，不能用目录条目推断。
对AI助手也是如此。读取产品目录可以减少名称混淆，却不能单凭“目录存在”就推荐用户启用某项服务，或承诺某个地区、版本与账户可以使用。产品发现、能力核验和交易授权是不同步骤，应各自保留依据。
重分类会改变资源名，映射应保留历史
官方介绍了一种值得系统设计者关注的生命周期变化：独立产品可能重新归类成变体，或者发生相反变化。重分类会改变资源名称，Get与List接口用Replaced和Replacement元数据指示它是否被替换以及新的资源名称。
如果内部系统把资源名当作永远不会变化的主键，却没有替换关系处理，重分类可能被误认为“旧产品消失、新产品诞生”。历史成本、文档链接或负责人映射就可能断开。更稳妥的方式是保留旧标识到新标识的关系，同时记录何时观察到变化，避免覆盖历史事实。
本文建议先将目录变化作为待核对事件进入管理流程。自动同步可以更新基础名称与关联，但涉及本组织责任分配、采购限制或合规标签时，不宜只因上游分类变化就无条件改写人工维护内容。官方分类和内部治理可以关联，不必完全重合。
公开数据仍受速率限制
官方说明，这一API暴露的是Google公开数据，访问不需要额外的项目级IAM权限，但请求仍按Google Cloud项目计数并受QPS限制。REST与MCP参考入口同时提供给开发者，适合不同接入方式；不能把公开数据理解为没有配额或可无限抓取。
接入可以从一个小范围的只读同步开始，保存完整响应、抓取时间与失败状态，检查分页及替换关系，再与现有目录比较。若某轮同步失败，应保留上一份可信目录并标记过期，避免把临时空结果传播成产品全部下线。
这次GA的价值在于让名称、层级与生命周期有统一的官方数据入口。围绕它建立可追溯映射，比定期手工改几处品牌名称更可维护；而内部资产、费用与决策记录仍需要各自可信的数据来源。
