本地数据库迁移

先确认实际数据库引擎与版本、迁移工具、已应用版本、表量级和并发访问。从现有迁移历史与部署顺序定位修改范围；缺少数据库版本、数据规模等关键信息时，先完成静态方案与待验证项，不宣称零停机。

迁移设计

• 已执行的版本化迁移可能受校验和管理，不改写它来修复历史；依据项目工具增加新的修正迁移。未应用的本次文件可在确认归属后修订。
• 列重命名、拆分或类型变化采用适合项目的扩展、兼容读写、分批回填、核验、切换、最后收缩。旧客户端或旧服务仍在使用时，不立即删掉其依赖字段。
• 区分结构变化与长时间回填。回填使用稳定键、有界批次和恢复位置，并验证重跑是否会覆盖新写入或重复生成结果；避免在一个巨大事务内处理全表。
• 新增 nullable 列仍可能获取元数据/表锁，不能称为“无锁”。DEFAULT、NOT NULL、索引和 DDL 事务行为依引擎及版本判断。PostgreSQL 的并发建索引有事务限制与失败残留；MySQL 的在线 DDL 选项不能直接套 PostgreSQL。执行前查目标版本官方文档。
• 恢复计划区分应用回退、schema 恢复和数据恢复。删除列或有损转换不能靠 DOWN 文件保证恢复；需要可验证的备份/恢复或前向修复方案。遵循项目迁移工具能力，不强制所有工具都有 DOWN。

验证与执行范围

在有授权的隔离数据库或 fixture 上验证迁移链、约束、旧/新代码兼容、回填恢复与真实可逆性；涉及大表性能时需有相应数据规模及锁等待证据。没有服务或代表性数据时，只交付静态检查和准确缺口。准备迁移文件不代表批准执行生产变更；生产执行仍遵守当前授权。

参考锁语义：PostgreSQL 官方说明。该 current 页面不代表项目锁定版本。