C#怎么创建EF Core迁移_C# Migration数据库迁移方法教程【实战】

C#怎么创建EF Core迁移_C# Migration数据库迁移方法教程【实战】

这里有一个必须牢记的操作顺序：先执行 dotnet ef migrations add，再执行 dotnet ef database update。如果跳过第一步直接去 update，数据库结构不会有任何变化，EF Core 也不会抛出明确的错误——它只会静默地、什么都不做。

dotnet ef migrations add 命令在哪执行、为什么总报“找不到 DbContext”

这个命令必须在包含 AppDbContext 类的那个项目目录下运行。注意，是项目目录，不是解决方案的根目录，也不是其他类库的目录（除非你的 DbContext 确实定义在那个类库里）。

经常遇到的报错 Unable to create an object of type 'AppDbContext'，其根本原因在于 EF CLI 工具在启动时无法成功构造你的上下文实例。通常逃不出下面几种情况：

• AppDbContext 的构造函数依赖了某些服务（比如 IConfiguration 或自定义的仓储接口），但这些服务在 CLI 环境下并未注册——因为 CLI 不走你 Program.cs 里配置好的那个 DI 容器。
• 项目里存在多个 DbContext 的子类，但你在执行命令时没有通过 --context 参数来指定到底用哪一个。
• 上下文缺少一个无参构造函数，同时你又没有重写 OnConfiguring 方法来提供连接字符串（CLI 默认不会去调用这个方法）。

一个稳妥的解决方法是，为 AppDbContext 专门添加一个仅用于迁移的构造函数：

public AppDbContext() : base(new DbContextOptionsBuilder()
    .UseSqlServer("Server=.;Database=TestDb;Trusted_Connection=true;")
    .Options)
{ }

当然，更推荐的方式是在运行命令时显式地传递所有必要参数，一劳永逸：
dotnet ef migrations add InitialCreate --project MyDataProject --startup-project MyWebProject --context AppDbContext

生成的迁移文件里 SQL 不对，比如缺索引、字段没加 nullable=false

这里有个关键认知：EF Core 迁移并不是去读取现有数据库的结构，而是将你当前的代码模型与上一次生成的 ModelSnapshot 文件进行对比。所以，当生成的 SQL 不符合预期时，问题往往出在这个对比的“基准”上：

• 你是否手动修改过上一个迁移文件里的 Up() 方法？比如删掉了一行注解（Annotation）。后续的 add 命令会基于这个“被篡改”的快照继续推导，结果自然就偏了。
• 你在实体类中使用了 Fluent API 进行配置（例如 modelBuilder.Entity().HasIndex(e => e.Email)），但 ModelSnapshot 文件并没有同步更新。这种情况常常发生在你忘记执行 add 就直接 update 之后。
• 你给字段加上了 [Required] 特性，但数据库列却依然是 NULL。这可能是因为你的修改是针对一个已经被应用过的迁移，而 EF 只对比快照，并不会去检查数据库中实际的结构。

如何验证？可以尝试删除刚生成的迁移文件，然后重新执行 dotnet ef migrations add CheckIndex，观察新生成的文件里是否包含了 migrationBuilder.CreateIndex 语句。如果还是没有，那问题很可能出在模型配置本身没有生效，而不是迁移命令的问题。

dotnet ef database update 报 “There is already an object named 'XXX'”

这大概是开发环境中最典型的冲突错误了。它的意思是，EF 假设数据库是空的，或者会严格按照迁移链的顺序干净地演进，但实际情况是，数据库里已经存在同名的表、约束或绑定了默认值的列。典型的错误信息包括：

• There is already an object named 'Users' in the database
• Cannot drop column 'CreatedAt' because it is bound to a default constraint

根本原因在于：EF 生成的 SQL 脚本（尤其是 Down() 方法或涉及重命名、删除列的操作）默认假设目标数据库的状态是可逆的、没有残留物的。解决路径需要根据场景来选择：

• 纯开发早期：直接删除 Migrations 文件夹，并清空本地数据库，然后从头执行 add InitialCreate。这是最快速的“清零”方法，但仅限于你自己的开发机器。
• 已有协作分支：不要轻易删除迁移文件。改用 dotnet ef migrations script --from 0 --to LatestMigrationName 命令生成全量的 SQL 脚本，然后手动剔除脚本中诸如建表前的 IF NOT EXISTS 检查或会导致冲突的语句，再执行这个修改后的脚本。
• 紧急绕过校验（不推荐）：使用 dotnet ef database update --force 参数。它会跳过部分存在性检查，但无法解决约束绑定等更深层次的问题，该报的错可能还是会报。

真正安全的做法，尤其是在生产环境，永远是：不要直接使用 update 命令，而是通过 script 命令导出 SQL 脚本，交由 DBA 审核后再手动执行。

最后，记住一个核心原则：一旦迁移链开始运转，ModelSnapshot 文件就是唯一的“事实基准”。它并不反映数据库的现状，只代表“上一次执行 add 时，我们认为的模型应该是什么样子”。很多人被卡住，就是因为眼睛只盯着数据库的实际结构去改代码，却忘了那个决定性的快照文件早已被固化。所以，每次执行 add 之前，先确认快照与当前代码模型是否一致，比什么都重要。