题干与适用场景
公司准备在 12 个月后关闭 v1 API，推出 v2。v1 有 3,000 个客户，约 40% 的请求仍依赖旧字段，其中 200 个客户是高收入企业。请规划迁移方案，兼顾新能力、兼容性、开发者体验、收入风险和最终下线。
这道题考察产品经理如何把一次技术迁移变成有边界的客户产品：先确认谁受影响、为什么要迁移和哪些行为不可破坏，再设计兼容层、工具、沟通、分批推进和退出条件。GitHub 的 API 版本文档把破坏性变更、Deprecation/Sunset 头、支持窗口和迁移测试都作为版本治理的一部分，可作为现实约束。
面试官考察点
第一项是能否把客户分群和风险排序说清楚，而不是只宣布一个日期。高收入、强合规、低活跃和自助客户的迁移阻力不同。
第二项是能否区分兼容、迁移和下线。保留旧版本、提供适配层或批量转换只能降低风险，不能替代客户确认和最终退出标准。
第三项是能否用可观测数据推进决策。请求量下降不等于迁移完成，要同时看活跃应用、错误率、字段使用、成功迁移和客户支持负担。
回答前需要澄清的问题
- v2 的核心价值是什么？ 是安全、性能、合规、成本，还是新资源模型？
- 哪些 v1 行为是破坏性变化？ 字段删除、类型变化、认证变化和错误语义都要列出。
- 客户是否知道自己使用了哪些字段？ 能否提供按 token、应用或组织的调用明细？
- 12 个月是硬截止还是目标日期？ 哪些证据可以触发延期或分阶段关闭？
- 能否运行双版本或适配层？ 成本、延迟和数据一致性边界是什么？
- 下线后的支持承诺是什么？ 410、错误文档、客户申诉和安全例外如何处理？
30 秒回答框架
“我先建立 v1 使用基线和客户分层，逐项列出 v2 的破坏性变化与迁移收益。然后发布兼容指南、差异清单、验证工具和按应用维度的用量看板，先邀请高价值客户和内部集成做试点。迁移期间同时发送文档、控制台、邮件和直接客户沟通，并用 Deprecation/Sunset 头和阶段性错误演练提高可见性。每个阶段有采用率、错误率、活跃应用迁移率和支持工单阈值；达到退出条件后才关闭 v1，保留安全例外和回滚窗口。”
分步骤深入解答
第一步：定义迁移目标和不可破坏的行为
把目标拆成客户价值和平台约束：例如 v2 提供更细粒度权限，v1 的核心读写语义必须在过渡期保持稳定。建立破坏性变化清单，包含删除或重命名字段、增加必填参数、类型变化、枚举变化和认证要求变化。不要把“接口返回 200”当成兼容证明。
第二步：建立使用基线和风险分层
按组织、应用、token、版本、端点、字段、请求量、收入、合规和技术负责人分层。给每个应用计算近 90 天活跃度、受影响字段比例、迁移复杂度和客户价值。高收入但低请求量的客户仍需要专人确认；没有明确 owner 的应用要提前进入风险队列。
第三步：设计迁移路径和兼容边界
优先提供 additive 迁移：新增可选字段、并行返回或 v1 到 v2 的适配层。对无法兼容的字段给出等价映射、示例请求和明确的语义变化。适配层要有期限、成本和观测，不应永久隐藏客户没有完成迁移的事实。
第四步：把工具和文档做成产品
提供差异清单、按应用的调用报告、静态检查或 SDK 迁移提示、沙箱验证、样例代码和回滚说明。文档要把每个破坏性变化连接到替代写法和测试步骤。迁移工具输出应可重复，避免客户只能阅读长篇公告后手工猜测。
inventory -> classify risk -> test v2 -> dual-run -> migrate -> verify -> retire v1第五步：安排分阶段发布和沟通
先让内部和设计伙伴双跑，再开放自助迁移，最后处理高价值或复杂客户。每阶段同时使用变更日志、开发者文档、控制台横幅、邮件和客户经理沟通。把日期、影响、动作、支持入口和例外条件写成同一份迁移契约，避免不同渠道传递不同承诺。
第六步：用信号而非单一采用率做门禁
每周看 v1 请求量、活跃 v1 应用数、受影响字段调用数、v2 成功率、迁移后回退率、弃用头覆盖率、支持工单和高价值客户确认率。迁移完成必须同时满足“应用已切换、关键场景通过、错误率没有异常、客户 owner 已确认”。
第七步：定义下线、延期和例外规则
下线前先在测试环境模拟 410 或等价错误，确认客户能看到动作指引。延期需要明确证据，例如安全修复未完成、关键合规客户仍在迁移或 v2 存在已确认回归。安全风险可以触发提前关闭，但必须说明影响、替代路径和支持范围。例外要有到期日，不能变成永久旁路。
第八步：复盘迁移并沉淀版本治理
下线后检查错误峰值、客户留存、支持成本、基础设施节省和未预期使用方式。保留 v1/v2 的差异、沟通记录、决定日志和事故时间线。把版本支持周期、破坏性变化评审、弃用头、迁移测试和客户通知纳入下一次发布模板，降低未来迁移的突发性。
设计取舍与边界
取舍一：兼容层还是快速切换
兼容层能降低短期风险，但会增加维护、延迟和语义歧义。只有当迁移价值明确、兼容边界可观测且有退出日期时才保留；否则应提供清晰的 v2 迁移窗口而非无限延长 v1。
取舍二：统一截止日期还是客户分批
统一日期便于运营，分批可以控制风险并给复杂客户更多时间。建议保留一个公开总截止日期，同时按客户风险设置里程碑和提前检查点，避免高收入客户在最后一周集中暴露。
取舍三：请求量下降还是应用真正迁移
请求量可能因业务下滑、缓存或停用而下降。应用迁移应以活跃应用、关键端点成功调用、字段替代完成和 owner 确认共同判断，不能只看总流量。
失败演练与演进计划
演练一：遗漏的破坏性字段
随机抽取真实请求回放到 v2，比较状态码、错误对象、分页、时区和金额语义。把差异按严重性分类，任何未解释的关键字段差异阻止扩大流量。
演练二：高价值客户在截止日前未迁移
提前 90 天生成客户清单，验证客户经理、技术支持和产品负责人都有明确 owner。为未响应客户提供一次技术诊断和限期例外，而不是在最后一天直接关闭。
演练三：下线后错误峰值
在小流量或沙箱中返回 410 与迁移链接，确认 SDK、监控和客户文档能引导修复。设置自动回滚或恢复旧路由的短窗口，并记录触发条件。
常见误区与追问
误区一：只发一封弃用邮件
通知不能替代使用清单、代码示例、测试环境和支持入口。迁移需要在客户实际工作流中可执行。
误区二：把版本号当成全部兼容性
同一版本内也可能有字段、错误和认证变化。必须维护逐项差异清单与契约测试。
误区三：永久保留旧版本
没有退出日期的兼容层会分裂文档、拖累基础设施并扩大安全面。每个例外都要有期限和负责人。
误区四：只按总请求量排序客户
低流量应用可能是关键账务或合规流程。分层应结合业务价值、受影响范围和技术复杂度。
误区五：忽略未版本化调用
依赖默认版本的客户可能在下线后看到行为变化。应主动识别未带版本头的请求，并在过渡期发出提示。
误区六：没有验证回滚和延期
只演练成功迁移无法证明风险可控。要提前验证错误引导、例外审批、回滚窗口和延期条件。