# 兼容性与迁移评估

> **事实纪律**:只记录已发现的消费者、数据、版本和能力。未知项必须保留为风险；合法不适用项写 `N/A（原因）`，不得用假设补齐。

> **产物定位**:brownfield(改造老系统/数据迁移/schema 变更/技术栈升级)时的条件产物(condition: brownfield,纯新系统不催产)。把改造的影响面、兼容性、回滚、风险定清楚,避免上线翻车。
> **核心纪律**:改造前先摸现状(证据先行,不凭记忆);破坏向后兼容须标注影响面;数据迁移须有恢复路径、验证状态和发布前完成条件;发布方式按风险与平台能力选择并说明依据。
> **反退化纪律**:影响面表/恢复方案表须逐条填真实值,禁止空表/「…」占位。
> **完成判定**:见文末。

## 现状

> 证据先行——靠真实运行/日志/数据证明,不凭记忆猜测。

- 现有系统行为:
- 历史遗留雷区(脆弱点/无人敢动的代码/隐式契约):

## 迁移范围与影响面

| 变更项 | 影响模块 | 影响数据 | 调用方 | 兼容性风险 |
|--------|---------|---------|--------|-----------|
| | | | | |

## 兼容性分析

- **向后兼容**:老接口/数据/调用方是否还能用?破坏点在哪?
- **数据兼容**:老数据能否被新代码正确读取?是否需要迁移脚本?
- **灰度能力**:能否新老并存、按流量/租户灰度切换?

## 回滚与恢复方案(必填)

| 变更项 | 首选恢复方式 | 数据兼容性 | 触发条件 | 验证方式与当前状态 |
|--------|--------------|------------|----------|--------------------|

> 恢复方式按风险选择：安全 down、expand/contract、备份恢复或前向修复。不可逆变更必须有备份、停止条件和发布前演练要求；尚未演练时写“未验证”及阻断影响，不得为满足格式编写会丢数据的 down 脚本。

## 风险与验证

- 新老逻辑比对:关键路径行为是否一致(比对日志/双写比对)
- 爆炸半径控制:根据变更风险和平台能力选择小切片、租户/区域/版本分段、并行兼容或一次性切换；无法分段时说明原因，并用更强预发布验证、开关隔离、备份或值守降低风险

## 完成判定

- [ ] 现状靠证据(运行/日志/数据),非凭记忆
- [ ] 影响面表逐条填(变更项/影响模块/影响数据/调用方/兼容性风险)
- [ ] 兼容性分析覆盖向后兼容/数据兼容/灰度能力
- [ ] 恢复方案表逐条填；每项迁移都有与风险匹配的恢复路径、当前验证状态和发布前完成条件
- [ ] 发布策略与风险和平台能力匹配；采用或不采用分段推进都有事实依据、停止条件和恢复方式