接口变更怎么审
接口评审的核心是兼容性：公有 API 的增删改会不会让调用方出错，默认值、错误码与序列化格式的变化是否被下游感知，以及版本策略与弃用流程是否完整。接口一旦发布，改动成本就从「改代码」变成「协调所有调用方升级」，因此这类改动值得评审时多花时间。
基本信息
| 检查对象 | 函数与方法签名、HTTP 接口、消息格式、配置项 |
|---|---|
| 兼容检查 | 字段增删、类型变化、默认值、错误码与序列化格式 |
| 弃用流程 | 先标记弃用、给出替代方案与时间窗，到期再移除 |
| 证据要求 | 涉及兼容性的改动应附影响面与回滚分析 |
逐项看什么
- 破坏性变更识别：删字段、改类型、改语义、改默认值。
- 序列化细节：可选字段是否变为必填，字段编号与键名变化的影响。
- 调用方盘点：公共接口变更是否覆盖了所有已知使用方。
- 错误语义：错误码与异常类型是否变化，调用方的分支逻辑是否会失效。
- 弃用流程：是否先标记、是否有迁移窗口、是否通知了相关方。
变更类型与兼容性
| 变更 | 是否破坏兼容 | 说明 |
|---|---|---|
| 新增可选字段 | 通常不破坏 | 调用方忽略即可，需注意默认值语义 |
| 删除或重命名字段 | 破坏 | 调用方解析会失败 |
| 修改默认值 | 常见隐性破坏 | 行为静默改变，最难排查 |
| 收窄参数取值范围 | 破坏 | 既有合法调用变为非法 |
| 放宽取值范围 | 一般安全 | 需确认下游能处理新值 |
兼容性检查清单
兼容性检查清单
# 1. 这次改动是否有字段删除、改类型、改默认值
# 2. 是否有调用方在按旧格式解析结果
# 3. 错误码与异常类型是否变化
# 4. 是否需要先发布兼容版本（新旧都支持）再切换
# 5. 是否给出弃用标记、替代方案与移除时间涉及兼容性的改动，评审时应要求作者给出兼容性与回滚分析，而不是事后补文档。
先扩后缩是常用节奏：新增字段与新路径先并行存在，确认调用方切换完成后再清理旧路径。