EF Core迁移冲突解决方法

EF Core 迁移报错“table already exists”本质是迁移历史与数据库状态不一致，应通过补录空迁移或重置迁移使二者同步，而非强行重跑。

EF Core 迁移报错 “table already exists” 通常不是真的冲突，而是迁移历史与数据库实际状态不一致。核心解决思路是：让 EF 认为已应用的迁移“对得上”当前数据库结构，而不是强行重跑。

检查迁移历史是否脱节

EF Core 通过 _EFMigrationsHistory 表记录哪些迁移已执行。如果该表缺失、被清空，或手动建了表但没记入历史，EF 就会误判为“还没创建”，从而在 Add-Migration 或 Update-Database 时重复建表。

• 用 SQL Server Management Studio 或其他工具查一下数据库里有没有 _EFMigrationsHistory 表
• 如果有，看看里面是否包含你预期已应用的迁移 ID（如 20231005142233_InitialCreate）
• 如果没有，或者有但缺少关键迁移记录，说明历史断了

修复方式一：补录迁移记录（推荐用于已有生产数据）

适用于：数据库已有正确结构和数据，只是 EF 不知道它已经存在。不改动表结构，只告诉 EF “这个迁移我早就跑过了”。

• 运行 Add-Migration FakeInit –NoBuild（加 –NoBuild 避免编译失败）
• 打开刚生成的迁移类，清空 Up(MigrationBuilder migrationBuilder) 和 Down(...) 方法体（留空即可）
• 运行 Update-Database —— 这次 EF 会把这条空迁移写入 _EFMigrationsHistory，不再尝试建表

修复方式二：重置迁移（仅限开发/测试环境）

适用于：本地开发库、无重要数据、愿意从头来过。操作快但会丢数据或需重新初始化。

• 删掉所有迁移文件（Migrations 文件夹下的 .cs 和 .Designer.cs）
• 删除数据库（或用 Drop-Database）
• 运行 Add-Migration InitialCreate
• 再运行 Update-Database

预防后续再出问题

团队协作中，迁移冲突常源于多人同时改模型又各自 Add-Migration。几个实用习惯：

• 每次合并代码前，先 Update-Database 确保本地库是最新的
• 新增字段/表后，立刻提交迁移文件（.cs + .Designer.cs + .resx），不要只提模型变更
• 避免手动修改数据库结构；所有变更走迁移，哪怕只是加个索引
• 上线前用 Script-Migration 生成 SQL 脚本做审核，比直接 Update-Database 更可控

基本上就这些。关键不是“怎么绕过错误”，而是让 EF 的迁移元数据和真实数据库保持同步。多数时候，补一条空迁移就能稳住局面。