必须先执行 dotnet ef migrations add 再执行 database update；跳过 add 直接 update 不会变更数据库且无报错。add 命令须在含 AppDbContext 的项目目录下运行，报“找不到 DbContext”主因是构造函数依赖未注册服务、多上下文未指定 --context 或缺少无参构造函数；迁移 SQL 错误源于 ModelSnapshot 与当前模型不一致，如手动修改过历史迁移或 Fluent API 配置未生效；“对象已存在”错误因 EF 假设目标库为空或干净演进，实际有残留结构，开发期可删库重迁，协作/生产环境应使用 script 生成 SQL 并由 DBA 审核执行。
必须先执行 dotnet ef migrations add，再执行 dotnet ef database update；跳过 add 直接 update，数据库结构不会变，EF 也报不出错——它只是默默什么也不做。
dotnet ef migrations add 命令在哪执行、为什么总报“找不到 DbContext”
命令必须在包含 AppDbContext 类的项目目录下运行，不是解决方案根目录，也不是类库目录（除非 DbContext 就在那里）。常见报错 Unable to create an object of type 'AppDbContext'，本质是 EF CLI 启动时无法构造上下文，原因通常是：
-
AppDbContext构造函数依赖了未注册的服务（比如IConfiguration或自定义仓储），而 CLI 不走Program.cs的 DI 容器 - 项目里有多个
DbContext子类，但没用--context指定目标类型 - 缺少无参构造函数，且
OnConfiguring没重写（CLI 默认不调用它）
稳妥解法：给 AppDbContext 加一个仅用于迁移的构造函数：
public AppDbContext() : base(new DbContextOptionsBuilder<appdbcontext>()
.UseSqlServer("Server=.;Database=TestDb;Trusted_Connection=true;")
.Options)
{ }</appdbcontext>
或者更推荐的方式：显式传参运行命令：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 databaseCannot 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生成全量脚本，人工删掉建表前的IF NOT EXISTS或冲突语句，再执行 - 紧急绕过校验（不推荐）：
dotnet ef database update --force，它跳过部分存在性检查，但不解决约束绑定问题，该报错还是报
真正安全的做法永远是：在生产环境，不用 update，只用 script 导出 SQL，DBA 审核后执行。
迁移链一旦开始，ModelSnapshot 就是事实基准——它不反映数据库现状，只反映“上一次 add 时我们认为的模型样子”。很多人卡住，是因为盯着数据库结构改代码，却忘了快照早已固化。每次 add 前，先确认快照和当前模型一致，比什么都重要。
