ef core 的 code first 迁移需通过 add-migration 和 update-database 协同完成，跳过迁移直接改模型会触发 invalidoperationexception；首次迁移用 add-migration initialcreate 生成迁移类和 modelsnapshot 快照，再用 update-database 应用到数据库；模型变更后必须新增迁移，不可手动改库或删库；ef core 不支持自动迁移，仅支持显式、可审计的代码迁移。
EF Core 的 Code First 迁移不是“一键同步”，而是靠 Add-Migration 和 Update-Database 两个命令协同完成模型与数据库的差异管理。跳过迁移步骤直接改模型再运行程序，大概率触发 InvalidOperationException: The model backing the context has changed 错误。
怎么生成第一个迁移文件
项目中已有实体类和继承自 DbContext 的类后，不能直接连库跑代码——EF Core 会检测模型与数据库结构不一致并拒绝启动。必须先生成初始迁移：
- 在包管理器控制台（PMC）执行：
Add-Migration InitialCreate - 或在项目根目录用 .NET CLI 执行：
dotnet ef migrations add InitialCreate
这会生成两个东西：一个带 Up()/Down() 方法的迁移类（如 20260425145023_InitialCreate.cs），还有一个 Migrations/ModelSnapshot.cs 快照文件。后者是 EF Core 判断后续变更的基准，别手动删或改它。
如何把迁移真正应用到数据库
Add-Migration 只是生成变更描述，不会碰数据库。要让表建起来，必须执行：
- PMC：
Update-Database - .NET CLI：
dotnet ef database update
这两个命令默认应用所有未执行的迁移（按文件名时间戳排序）。如果只想执行某一次，比如只跑初始迁移，加参数指定名称：Update-Database InitialCreate。注意：生产环境严禁直接执行 Update-Database，应导出 SQL 脚本由 DBA 审核后再执行——用 dotnet ef migrations script 或 PMC 的 Script-Migration。
模型改了但迁移没更新，运行就报错
这是最常踩的坑：给 Blog 类加了个 Url 属性，没跑 Add-Migration 就直接 Update-Database 或启动程序，立刻抛出 The model backing the context has changed。原因很直接——快照文件里没记录这个字段，而数据库里也没有对应列，EF Core 拒绝妥协。
- 修复方式只有一步：
Add-Migration AddUrlToBlog（名字自定义），再Update-Database - 不要试图删掉数据库重来，尤其开发中已有测试数据；也不要手动在数据库里加字段，否则快照和实际结构会持续脱节
- 如果改的是主键、删了非空字段、改了类型（如
int→string），EF Core 默认生成的Up()方法可能含DROP COLUMN或数据丢失操作，务必打开迁移文件检查 SQL 逻辑
自动迁移（Automatic Migrations）能不能用
EF Core **完全不支持**自动迁移。这是 EF6 的功能，且官方明确不推荐团队使用——它绕过迁移文件，靠运行时对比快照和数据库动态执行变更，无法审查、不可追溯、容易在多环境间失步。EF Core 只提供显式迁移（Code-based Migrations），这是设计使然，不是遗漏。
别被旧文档误导。看到 Enable-Migrations 或 AutomaticMigrationsEnabled = true 这类配置，全是 EF6 的，EF Core 项目里写进去也没用，还会引发编译错误。
迁移的本质是把“模型变更”变成可版本化、可协作、可审计的代码文件。省略这一步，后面填坑的时间远超写两行命令的成本。
