# 兼容性评估正反例

正例是表达深度下限，必须用当前系统的真实调用方、数据量、脚本和观测证据替换。

## 正例

| 变更项 | 影响面 | 兼容策略 | 回滚触发 | 验证 |
|---|---|---|---|---|
| `orders.status` 增加 `cancel_pending` | API v1、报表任务、移动端 3.8 | 旧客户端继续接收 `processing`；服务端仅向 v2 返回新值 | 未知枚举错误率超过 0.1% | 影子流量比对 24 小时，按客户端版本统计反序列化失败 |

- 上线：先发布兼容读取代码，再执行 `migrations/20260715_add_order_status_up.sql`
- 恢复：停写新状态，将 `cancel_pending` 回填为旧版本可读的 `processing`，验证没有信息丢失后再切回应用；本例的 down 已用生产等价数据演练并证明可逆
- 数据验证：迁移前后总行数一致，新状态行数与业务事件数一致

好在：调用方、顺序、阈值来源、数据可逆性和验证证据可以执行；这里能安全 down 是本例事实，不是通用要求。

## 反例

- 影响：可能影响旧系统
- 兼容：尽量兼容
- 回滚：有问题就回滚
- 验证：上线后观察

问题：没有对象、顺序、脚本、阈值和复验方法，无法支持发布决策。

## 迁移到当前项目

替换调用方、版本、数据量、窗口、脚本、指标和责任人。兼容结论须来自真实依赖扫描、流量/数据事实、演练或负责人确认；无法枚举的消费者必须作为风险保留。