直接回答

处理接口版本兼容的核心策略是：默认保持向后兼容，破坏性变更必须走"新版本并行 + 平滑迁移"流程。常见手段包括 URL 或 Header 版本号（/v1/、/v2/）、只增不删的字段演进、废弃公告与宽限期，以及多版本共存一段时间后再下线旧版。

展开解析

具体分三层。一是预防：首选非破坏性演进——加可选字段、加新端点，避免改类型、删字段、改语义；Protobuf 这类带字段编号的 schema 天然支持兼容演进，配 schema registry 做检查。二是变更流程：确认必须破坏兼容时，v2 与 v1 并行运行、网关路由；提前公告废弃时间表，用 Deprecation/Sunset 响应头和监控观察旧版流量，主动联系调用方迁移。三是内部配合：消费者侧用容错性读取（只取认识的字段）、契约测试（如 Pact）在 CI 拦截破坏；数据库变更采用"扩展-迁移-收缩"多阶段发布，保证滚动升级中新旧代码都能工作。易错点是只给接口打版本而忽略事件消息和数据库这些"隐性接口"。追问：内部 RPC 与公开 API 的策略差异、金丝雀发布如何配合版本切换。