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 的迁移元数据和真实数据库保持同步。多数时候，补一条空迁移就能稳住局面。
