EF Core 迁移失败主因是数据库状态、迁移文件与_EFMigrationsHistory三者不一致；应优先校准元数据而非重跑命令，如添加空迁移同步历史。
EF Core 迁移失败，90% 不是代码写错了，而是数据库状态和迁移元数据不一致。 直接重跑 Update-Database 通常会让问题更糟——它只会按迁移文件“以为”的状态去执行，而那个状态很可能已经过期或错位了。
为什么 Update-Database 总报 “table already exists” 或 “column does not exist”？
本质是 _EFMigrationsHistory 表里记录的迁移历史，和你当前数据库实际结构、以及代码中迁移文件所描述的结构，三者对不上。EF Core 不会“智能推断”你手改过什么，它只认快照 + 历史表 + 迁移文件这三件套。
- 常见诱因：手动在 SQL Server Management Studio 里删过表、加过列、改过约束，但没走迁移流程
- 另一个高发场景：团队中有人
Remove-Migration后没同步 .Designer.cs 文件，导致快照残留旧模型 - DBA 提前建好了表（比如用脚本初始化），但 EF 还以为自己要从头建——这时
Update-Database就会撞上There is already an object named 'XXX' in the database
补一条空迁移，比删库重来更安全（生产环境首选）
适用于：数据库已有正确结构和真实数据，只是 EF 不知道“这事我干过了”。目标不是改结构，而是让元数据追上现实。
- 运行
dotnet ef migrations add FakeInit --no-build（--no-build防止因模型编译失败中断） - 打开刚生成的
*FakeInit.cs，把Up和Down方法体清空，只留花括号：protected override void Up(MigrationBuilder migrationBuilder) { } protected override void Down(MigrationBuilder migrationBuilder) { } - 再执行
dotnet ef database update—— 这次它会把这条空迁移写进_EFMigrationsHistory，后续迁移就能接着往下跑了
临时表（#TempData）迁移失败？先确认它该不该进迁移
本地临时表（#xxx）在连接断开后自动销毁，根本不该出现在迁移里。EF Core 默认会尝试为每个 DbSet 生成建表语句，一碰临时表就炸。
- 如果只是运行时用，加
.ExcludeFromMigrations()：modelBuilder.Entity().ToTable("TempData", t => t.ExcludeFromMigrations()); - 如果必须参与迁移（比如全局临时表
##xxx），得显式声明无主键：modelBuilder.Entity().HasNoKey(); - 命名必须合规：SQL Server 要求本地临时表以
#开头，EF Core 默认生成的表名不含这个前缀，硬配会出错；真要用，得在ToTable里写死：modelBuilder.Entity().ToTable("#TempData");
迁移命令找不到项目？检查三个硬性路径条件
dotnet ef 不是全局命令，它依赖当前目录下能定位到 .csproj 和已安装的 EF Core 工具包。
- 必须在包含
YourApp.csproj的目录下执行，不能在Models/或Migrations/子目录里 - 确保已全局安装工具：
dotnet tool install --global dotnet-ef，且版本与项目引用的Microsoft.EntityFrameworkCore.Tools大版本一致（如都是 8.0.x） - DB First 场景下，
scaffold命令还要求连接字符串里权限足够——至少要有VIEW DEFINITION，否则连表结构都读不出来，自然无法生成迁移起点
最易被忽略的一点：迁移不是“执行 SQL”，而是“协调状态”。只要 _EFMigrationsHistory 里少了一条记录，或者某次 Up 方法里漏掉了一个 migrationBuilder.Sql(...)，后续所有迁移都会基于错误的前提推进。所以别急着删迁移文件，先查表、看日志、比快照——状态对齐了，问题就解决了一大半。
