订单系统需要把数据库字段 customer_name 改为 buyer_name。发布期间新旧两个版本的应用会同时运行。为了尽量避免停机和版本不兼容，最合理的步骤是（）。
平滑模式变更要让相邻版本有一段兼容窗口。先扩展结构，再迁移数据和流量，最后在确认无人依赖旧结构后收缩，避免旧实例立刻报错。
选项分析
错误。旧版本仍读取 customer_name，会立即失败。
正确。通过扩展、迁移、收缩建立版本兼容窗口。
错误。连接池不会自动修复SQL中的字段依赖。
错误。文档变化不能替代真实的数据结构和代码迁移。
本题为什么容易错
开发环境一次性升级看不出问题，滚动发布却会让多个版本短暂共存。题目只要强调不停机或灰度，就必须把兼容窗口考虑进去。
简短答案
不停机发布时，数据库字段为什么不能先改名再上线应用，正确答案是 B（先增加 buyer_name并保持兼容，部署迁移版本完成双写或回填，确认旧版本退出后再删除旧字段）。平滑模式变更要让相邻版本有一段兼容窗口。先扩展结构，再迁移数据和流量，最后在确认无人依赖旧结构后收缩，避免旧实例立刻报错。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| 先删除 customer_name，再发布只读取 buyer_name 的新版本 | 本题干扰项 | 错误。旧版本仍读取 customer_name，会立即失败。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 先增加 buyer_name并保持兼容，部署迁移版本完成双写或回填，确认旧版本退出后再删除旧字段 | 本题正确答案 | 正确。通过扩展、迁移、收缩建立版本兼容窗口。 | 看到题干核心场景时优先联想到它 |
| 在所有实例运行时直接改名，并假设连接池会自动适配 | 本题干扰项 | 错误。连接池不会自动修复SQL中的字段依赖。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 只修改接口文档，数据库和应用无需变化 | 本题干扰项 | 错误。文档变化不能替代真实的数据结构和代码迁移。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- 先删除 customer_name，再发布只读取 buyer_name 的新版本：错误。旧版本仍读取 customer_name，会立即失败。
- 在所有实例运行时直接改名，并假设连接池会自动适配：错误。连接池不会自动修复SQL中的字段依赖。
- 只修改接口文档，数据库和应用无需变化：错误。文档变化不能替代真实的数据结构和代码迁移。
知识点详解
Expand阶段只做兼容性增加，例如新增可空字段或表；Migrate阶段部署兼容代码、双读写或回填并观察一致性；Contract阶段在所有消费者迁移完成后移除旧结构。每一步都应可监控、可回退。
备考速记
先加路，再迁车，确认旧路没人走，最后才封路。
Expand-Contract 在向后兼容场景中的作用
实际项目可先让新代码仍读取旧字段但同时写两列，回填历史数据后切读新字段，观察一个完整业务周期，再通过依赖扫描和访问指标确认旧字段无调用。
同类题怎么考
- 选择数据库零停机发布顺序。
- 识别滚动发布中的前后版本兼容风险。
Expand-Contract 在系统架构设计师软考中的考法
看到新旧版本共存，优先排除先删除、先改名等破坏性方案。正确答案通常会给出兼容、迁移验证和最后清理。
解题思路
按时间线判断最清楚。T1 新旧应用都在，数据库必须同时支持它们；T2 数据回填和读写切换完成；T3 旧实例和下游消费者都不再访问 customer_name，才具备删除条件。只有 B 满足这条时间线。
考点定位
字段改名在兼容发布里通常拆成新增与删除两次变化。删除属于破坏性操作，必须最后做。
易错提醒
- 新字段允许空值，但旧代码写入后没有同步新字段。
- 回填完成就删旧字段，忘记报表和离线任务仍在读取。
- 双写没有幂等和监控，产生两列数据不一致。
备考提示
- 画三阶段时间线：扩展、迁移、收缩。
- 删除字段前盘点在线服务、批处理、报表和外部消费者。
你可能还想了解
- 数据库字段改名如何不停机？
- Expand-Contract分哪几个阶段？
- 滚动发布为什么要向后兼容？
本文小结
数据库平滑变更应先扩展兼容结构，再迁移数据和读写，最后确认依赖清零后删除旧结构。