同一个接口能跑通新版本，旧报表却在第二天把未知金额算成了零。后端面试里，如果题目是升级第三方 API，招聘方很可能会问谁会受到影响。GitHub REST API 的文档说明了用请求头指定 API 版本和阅读破坏性变更；Stripe 的 API 参考也说明了版本机制，并提醒测试新版本。两者的具体配置有差别，案例借用的是有意指定版本、逐项验证的做法。 GitHub API 版本 · Stripe API 版本
把调用方和输入方向画出来
设想一个课程项目有订单查询、每日统计和异步事件处理三个入口。查询接口在用户打开页面时请求供应商，统计任务会批量读取本地快照，事件处理器从供应商接收订单变化并写进快照。三条路的触发方式不同。只调整查询请求头，不会自动迁移已经保存的数据，也不会改变对方发送到事件接收端的格式。先说明哪一处读旧字段、哪一处写本地状态，哪些地方会在应用重新发布后继续处理旧消息。
还需要问清部署时两边能不能同时升级。若后台与移动端由不同团队负责，移动端更新可能落后几周，服务要在这段时间理解两种输入。第三方平台的历史事件也可能晚到。面试官在意你能否先找到这些边界，再决定在哪里做转换。画图时只保留有助于判断影响的入口和数据方向，先别讨论无关架构。
把字段变化翻译成业务规则
模拟旧版本返回金额和币种，金额以最小货币单位表示。新版本把金额放在 settlement 对象下，暂未结算时对象为空。领域层可以仍保留订单号、状态、金额是否已知、金额值和币种。若新对象为空，语义是未知。若供应商给出零，表示已知的零。报表统计时可以将未知订单另行计数，前端显示待确认。不应让未知数据触发免付或错误完成状态。
同样要问新旧字段是否可同时出现。若供应商明示兼容期里两者都可能存在，先按实际版本解析。出现互相冲突的值，就记录冲突并保留原始响应供诊断，不能简单将两个金额相加。若单位也变化，测试时拿一条能暴露倍数错误的样本。例如旧值 1250 与新文档的单位解释必须得到同一个业务金额，使用小数的地方还要讨论精度与舍入。模拟题中的版本字段属于教学设置。
设计可以把错误逼出来的响应
| 输入 | 应观察的输出 |
|---|---|
| 旧响应含 1250 与币种 | 被正确映射到内部金额，旧报表仍读取 |
| 新响应对象含零值 | 被标为已知零，不触发待确认 |
| 新响应的金额对象为空 | 进入未知金额路径，统计能区分 |
| 已处理事件的旧版本副本晚到 | 业务状态不被重复更新或倒退 |
| 签名检查失败或字段畸形 | 拒绝或隔离，并保留可追查的错误信息 |
测试从领域对象和实际业务行为看效果。只断言返回 HTTP 200，无法证明落库金额没变。可以跑一段比较脚本，拿同一批订单的总数、已知金额之和、未知金额数量进行逐项核对，再抽样点开最复杂的一条。事件需要有原始标识与处理结果，便于看重复投递是否影响业务状态。至于实际签名格式和事件幂等规则，回到所用供应商的官方文档确认。
让旧记录和新记录能在一段时间共存
先写一个只读取已识别格式的转换层。系统里已有的快照按原版本解析，新版本数据记录自己的来源和版本。尝试先在测试环境用一组不会写真实业务的请求运行，再在生产选择明确的小范围验证。若需要影子请求，应确认它的成本、授权及是否带来副作用。读取两个版本并对比的做法适用于授权的只读路径，不能把一笔真实订单创建两次来观察差别。
遇到长时间运行的任务，要说明什么时候切换。假设批处理在换版时跑到一半。可以把版本与批次标识固定在作业开始时，后续续跑按同一规则。如果需要从半途重跑，记录处理到哪里、哪些行已经提交，以及怎样防止同一行被重复计入。相比一句“所有调用者一起升级”，这些细节能让面试官看到你理解真实的迁移节奏。
回滚之前先问改动已经写进哪里
如果只是增加支持新输入的读取逻辑，流量切换失败时可能关掉新请求，再继续解析旧数据。如果新版已经写了旧程序看不懂的记录，直接回滚程序可能扩大故障。可以让新程序先兼容读取，在未确认时不改变旧数据的格式；若必须改变存储，需准备兼容窗口或能重建旧视图的方案。具体操作取决于项目是否能保留原始记录和迁移历史。
也要预想第三方停止提供旧版的情况。届时回滚到旧请求头可能只得到接口错误。应安排可用的低风险路径，例如在数据过期时暂时展示上一次确认的快照并标记更新时间，或者限制会造成错误订单动作的功能。把这种用户可见的变化放进发布说明，写明谁能决定恢复以及用什么证据确认。
把面试答案讲成一次小型交付
演示时先用半分钟交代三个调用方向，然后说你为什么保留未知金额，再打开一条零值测试。随后请对方改一项条件，例如事件同时到达或旧移动端还要继续用一月。你可以指出要增加哪个契约样本、重新核对哪项存储规则，以及什么情况下需要延迟切换。最后给一条证据说明迁移已完成，比如所有识别出的入口都已采用明确版本，错误量可观测，旧格式的历史记录仍能被读取。若你只验证了模拟服务，也把它说清楚，方便团队追问怎样补真实环境。
用一张清单协调并行团队的验收
如果查询端、事件端和报表各有维护者，可以给每组一行任务。查询端确认请求版本和金额解析。事件端确认签名、历史事件和重复投递。报表组核对已知金额和未知数量。再写一个跨组验收样本：同一订单先收到旧版本事件，后来查到新版本的金额，在第二天报表里按明确日期落入正确行。谁能查供应商状态、谁能回退入口、谁复核业务结果，都可以在发布前列清。
有时一个调用方不响应或无法升级。面试里可以提出从访问日志核对是否仍在使用旧路径，并为这个调用方保留一个有截止日期的兼容安排。日志能说明你看见了什么，不能证明没有低频客户端。可以继续查调度计划和登记信息，避免刚好一个星期没运行就判断它已下线。确认旧版本何时停止接入也需要与实际拥有者同步。
最后可以在作品集给出两个故障对照。一条说明新版未知金额进了独立路径，一条说明重复事件没有改变已经确认的业务状态。让面试伙伴只看两条记录，复述哪个入口变了、哪个行为保持一致。若他只能复述新字段名，说明你的项目还少了一段业务验收说明。
常见问题（FAQ）
第三方 SDK 升级成功就代表迁移完成吗？
还需验证真实调用路径、返回字段语义、异步事件以及失败时的恢复方式。
旧接口字段缺失可以都补成零吗？
需要看领域含义。金额为零、金额未知与权限限制可能对应不同后续行为。
项目没有线上流量也能做迁移练习吗？
可以用模拟服务或固定响应跑新旧契约测试，说明没有验证的线上流量与第三方限制。
- GitHub REST API Versions· GitHub
- Stripe API versioning· Stripe
带上做过的集成项目，找出调用方、旧数据样本和迁移验收规则。