Compute Engine日期式API版本正式可用：资源清单要识别部分成功
2026年9月29日，Google Cloud宣布Compute Engine的Interface-based versioning（IBV，接口式版本管理）正式可用。调用方可选择一个明确的日期版本，按自己的计划采用接口变化。同日公告还区分了2026-09-01稳定版和2026-10-01-preview预览版：前者已GA，后者仍在预览，不能只看版本日期就把两者视为同等级接口。
配图为AI生成的概念插图，表现不同API版本的独立通道，不是真实产品界面。
旧接口继续工作，版本选择成为显式契约
官方指南说明，IBV的引入不会直接破坏现有CBV v1实现。未指定版本的请求默认走CBV v1，已有请求可以继续使用；若要访问IBV的新能力，再选择相应版本。因此，这不是要求所有自动化在同一天更换接口地址的强制迁移通知。
日期式稳定版本使用YYYY-MM-DD形式，预览版本附加-preview。调用方通过查询参数或请求头指定目标版本。其价值在于把“服务器今天怎么解释这个请求”转化为可以记录、测试和审查的接口选择。对维护很多脚本的团队，版本不应只留在某位工程师的命令历史里。
新接入也不宜简单追随日期最大的版本。预览接口可能调整或移除能力，官方不建议用于关键生产环境。稳定业务可以锁定已验证的稳定版本，把预览功能放进独立试验，避免一个探索性依赖把整套资产与权限自动化一起带入变动范围。
默认返回部分结果，盘点成功的定义要更严格
2026-09-01版本的一项明确行为变化是：当某个范围不可达时，aggregatedList默认返回部分结果；aggregatedList和list方法不再提供returnPartialSuccess查询参数。这会影响把接口响应直接当作完整资产清单的程序。
举例说，一个定时任务汇总多个区域的实例。如果某个范围暂时不可达，能够拿到其他范围的结果，对继续运行很有帮助；但下游若把缺失实例全部视为已删除，就可能生成错误报告或触发不恰当的清理。风险来自业务如何解释不完整清单，而不只是HTTP请求是否成功。
因此，迁移验收应至少包括完整结果、分页结果和部分范围失败三类样例。清单记录应保留覆盖范围、告警和本次是否完整的状态。只有在确定数据完整时才比较删除项；无法确认时，可暂存新观察而不覆盖上一份可信快照。这是本文的工程建议，适用于依赖资产枚举的系统，并不是Google自动替应用提供的保护逻辑。
预览版的配额字段调整，需要单独隔离
同日开放的2026-10-01-preview中，projects.get、regions.get和regions.list响应不再包含quotas字段。官方要求通过Cloud Quotas API查看和管理配额。这是预览版接口的变化，应与稳定版的部分结果语义分开测试。
如果原来一个请求同时承担“读取资源信息”和“获取配额”两项职责，迁移到这一路径之后就需要重新整理依赖。先列出谁读取quotas字段，再评估新增接口的身份、失败处理和调用频率，比捕捉空字段后直接填零更可靠。配额不可读取与可用配额为零含义不同，监控系统尤其不应混淆。
SDK升级也可能意味着接口版本升级
版本指南指出，Cloud Client Libraries的发布与具体日期式API版本对应；Terraform提供者则封装底层版本选择，配置不要求手工写版本请求头。由此可见，团队不能只审查手写REST请求，还要把客户端库与基础设施提供者的升级纳入兼容性检查。
较合理的落地顺序，是先盘点调用入口，标出生产、测试与预览用途，然后记录依赖版本和关键响应样例。升级时比较字段、分页、告警和错误路径，最后再验证业务报告是否一致。版本固定能降低无意变化，但不会替代调用方对结果完整性的判断。
对云平台工具维护者，这次GA提供了更明确的变更边界。真正值得建立的习惯，是同时记录“调用了哪个版本”与“这次结果覆盖了哪些范围”。两者都明确，版本管理才会转化为可解释的生产行为。
