NestJS中TypeORM迁移的最佳实践及相关问题咨询

关于synchronize: true的环境选择 #

• 开发环境：个人小项目或快速原型阶段，临时启用synchronize: true能省不少手动写迁移的时间。但如果是团队协作、或需要和正式迁移流程对齐，强烈建议禁用——因为synchronize直接修改数据库结构，这些变更不会被迁移文件记录，后续生成迁移时TypeORM会误判实体与数据库的差异，导致迁移文件混乱，甚至覆盖已有变更。
• 测试环境：绝对禁用synchronize，测试环境要完全模拟生产环境的流程，用迁移同步结构，才能提前发现迁移中的潜在问题，避免到生产环节踩坑。

自动生成 vs 手动编写迁移 #

• 自动生成是可靠的，但不是万能的。日常结构变更（新增字段、修改字段类型、添加索引/外键）用typeorm migration:generate生成基本没问题，能节省大量重复工作。
• 生成后必须手动检查并调整：涉及数据迁移（批量更新字段值、拆分表）、复杂索引调整、或需要保留历史数据的变更时，自动生成的脚本往往不完整，甚至会有破坏性操作（比如直接删除字段），这时候就得手动修改迁移逻辑，确保数据安全。
• 核心业务表的关键变更，建议手动编写迁移，完全掌控每一步操作，避免自动生成脚本出现意外。

已部署应用的迁移处理流程 #

1. 预发布环境验证：迁移脚本在生产执行前，必须在与生产结构一致的预发布环境跑一遍，检查是否有报错、性能问题（比如大表锁表）、数据丢失风险。
2. 备份数据库：执行迁移前一定要做全量备份，万一出问题能快速回滚。
3. 保证迁移幂等：编写迁移时确保重复执行不会出错，比如用IF EXISTS判断表/字段是否存在，避免重复创建导致报错。
4. 数据迁移优先考虑性能：涉及大量数据操作时，不要一次性执行，分批处理，避免长时间锁表影响业务。
5. 准备回滚方案：TypeORM自动生成的迁移部分支持回滚，但复杂的自定义迁移需要手动编写回滚逻辑。保留好历史迁移文件，一旦迁移失败，能快速执行回滚脚本恢复。
6. 执行顺序：部署时先执行迁移，再启动应用新版本，避免应用连接到未更新的数据库结构导致报错。

内容的提问来源于stack exchange，提问作者Yahli Gitzi