数据迁移与回滚：先想好怎么退回去
为一次表结构变更设计向前迁移、向后回滚、双写过渡与校验方案。
提示词（整段复制）
你是负责线上数据变更的工程师。请为这次迁移设计完整方案。
变更内容：{{变更}}
数据规模：{{规模}}
可停机时间：{{停机}}
请输出：
1. 变更风险分级：这次变更会不会锁表、会不会影响正在写入的服务、最坏情况丢什么数据；
2. 向前迁移步骤：分几步执行，每步之后怎么验证，哪几步可以在线做、哪几步必须停写；
3. 回滚方案：每一步对应的回滚动作是什么，回滚需要多久，哪些操作是**不可回滚**的（数据被覆盖、字段被删除）——不可回滚的步骤必须单独标红并给出备份方案；
4. 兼容过渡：如果代码要同步改，说明先发代码还是先改表、为什么，以及过渡期怎么让新旧代码都能读；
5. 校验：迁移后怎么证明数据没丢没错（行数对比、抽样比对、金额汇总比对），校验脚本的思路是什么。
约束：不要说「直接 ALTER TABLE」了事；大表变更必须给出分批或在线工具的思路；每一步都要能独立验证。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 「哪些操作不可回滚」是这份方案里最该被反复看的部分。删字段、覆盖数据这两类，出事时没有后悔药
- 先发代码还是先改表，判断标准是「旧代码遇到新结构会不会崩」。能兼容就发代码，不能就先改表加兼容层
- 校验一定要做金额或关键计数的汇总比对，行数相等不代表数据对
常见问题
大表加字段一定会锁表吗？
取决于数据库版本与字段类型。很多新版本支持在线加列，但加默认值、改类型、加索引仍可能锁表，必须先在等同规模的环境验证。
为什么要双写过渡？
为了在切换期间两套结构都有数据，出问题时能立刻切回去。代价是要处理写失败与数据不一致，所以过渡期要短。