EF Core迁移需在DbContext项目目录执行，安装Microsoft.EntityFrameworkCore.Tools；Add-Migration生成迁移文件，Update-Database同步数据库，Remove-Migration撤回上一次迁移，Script-Migration生成SQL脚本供生产部署。
EF Core 迁移命令在 Package Manager Console 中怎么写
迁移必须在包含 DbContext 的项目目录下执行，且项目需安装 Microsoft.EntityFrameworkCore.Tools。常见错误是直接在解决方案根目录运行，导致提示“找不到 DbContext 类型”或“无法解析 DbContext”。
-
Add-Migration InitialCreate：生成首次迁移文件（含Up/Down方法），文件名可自定义，但建议语义化 -
Update-Database：将待应用的迁移同步到数据库；若指定名称（如Update-Database InitialCreate），则只执行到该迁移 -
Remove-Migration：撤回最后一次Add-Migration生成的文件（不触碰数据库），适合改错后重来
注意：Update-Database 默认连接字符串来自 Startup.cs 或 Program.cs 中的 UseSqlServer 配置，不是 appsettings.json 的默认节——除非你显式传入 -ConnectionString 参数。
使用 dotnet CLI 执行迁移时为什么报错“Unable to create an object of type 'AppDbContext'”
这是最常遇到的启动失败错误，本质是 EF Core 运行时无法构造你的 DbContext。根本原因通常是依赖注入链断裂，比如：
-
AppDbContext构造函数依赖了未注册的服务（如IConfiguration或自定义仓储接口） - 项目中存在多个
DbContext，但没用[DbContextOptions<t>]</t>明确指定目标类型 - 缺少无参构造函数，且
OnConfiguring未被重写（CLI 不走Startup的 DI 容器）
解决方法：在 AppDbContext 中补充一个仅用于迁移的构造函数，例如：
public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
public AppDbContext() : base(new DbContextOptionsBuilder<AppDbContext>()
.UseSqlServer("Server=.;Database=TestDb;Trusted_Connection=true;")
.Options) { }
或者更稳妥的方式：确保 dotnet ef migrations add 命令能识别你的启动项目和上下文类型，加 --project 和 --startup-project 参数。
迁移文件里生成的 SQL 为什么和预期不符？比如字段没加索引或约束丢失
EF Core 的迁移基于模型快照（ModelSnapshot）与当前 DbContext 模型对比生成，不是实时读取数据库结构。所以以下情况会导致 SQL 异常：
- 手动修改过迁移文件中的
Up方法，后续再Add-Migration会基于修改后的版本继续推导，产生偏差 - 实体类上用了
[Column(TypeName = "datetime2")]等特性，但忘了在OnModelCreating中配置对应索引或约束 - 使用了
HasIndex(e => e.Status).IsUnique()却没调用HasDatabaseName("IX_Orders_Status")，导致迁移名随机，难以追踪
建议始终用 Fluent API 在 OnModelCreating 中集中声明约束，避免混用 Data Annotations 和 Fluent 风格；迁移生成后，打开 Up(MigrationBuilder migrationBuilder) 方法检查 SQL 是否含 CREATE INDEX 或 ADD CONSTRAINT，别盲目 Update-Database。
生产环境部署迁移时如何避免直接执行 Update-Database
线上库不允许开发机直连，也不能依赖 PowerShell 环境。正确做法是把迁移编译成 SQL 脚本，交由 DBA 审核执行：
-
Script-Migration（PMC）或dotnet ef migrations script（CLI）生成完整脚本，默认从初始迁移到最新 - 加
-From和-To参数可限定范围，例如只导出 v1.2 到 v1.3 的变更 - 脚本不含
IF NOT EXISTS判断，执行前需确认目标库状态；若要幂等，得自己加包装逻辑或用--idempotent参数（仅限 SQL Server）
特别注意：脚本不会执行 Seed 数据（即 HasData），这部分仍需代码控制，或拆成独立部署步骤。
