EF Core回滚迁移需先用update命令回退数据库至目标版本，再考虑移除迁移文件；严禁直接删除已应用迁移；生产环境推荐用新迁移反向修正而非回滚。

EF Core 回滚迁移，核心是把数据库结构恢复到某个历史迁移版本的状态，而不是直接删除已应用的迁移文件。关键在于：迁移文件一旦应用到数据库，就不能用 remove 命令删掉——必须先“回退数据库”，再考虑是否移除迁移代码。

回滚到指定迁移版本

这是最常用、最安全的回滚方式。执行后，EF Core 会按顺序调用后续所有迁移的 Down() 方法，直到目标迁移为止。

• 命令格式（.NET CLI）：dotnet ef database update 上一个迁移名称
• 例如：当前最新迁移是 AddOrderStatus，想回退到 InitialCreate，就运行：
  dotnet ef database update InitialCreate
• 效果：数据库表结构、约束、索引等将还原为 InitialCreate 迁移完成后的状态
• 注意：__EFMigrationsHistory 表也会同步更新，只保留已执行到目标版本及之前的记录

回滚所有迁移（重置数据库）

适用于开发或测试环境，想彻底清空结构、从头开始。

• 命令：dotnet ef database update 0
• 含义：回滚到“零迁移”状态，即数据库中不包含任何 EF Core 管理的表（但 __EFMigrationsHistory 表仍存在）
• 后续可重新执行 dotnet ef database update 从头建库
• ⚠️ 生产环境严禁使用此操作

移除未应用的迁移文件

仅适用于刚添加、但还没执行 update 的迁移（比如本地写完 Add-Migration 后发现写错了）。

• 命令：dotnet ef migrations remove
• 它只会删掉最新的迁移类文件和快照中的对应记录
• 如果该迁移已执行过（哪怕只在本地数据库），此命令会失败并提示“迁移已应用”

已应用迁移的“删除”流程（谨慎操作）

想彻底删掉一个已上线的迁移？不能硬删文件。正确路径是：

• 第一步：用 dotnet ef database update 上一个迁移名 把数据库回退到位
• 第二步：确认无误后，再执行 dotnet ef migrations remove 删除该迁移文件（此时它已是“最后一个未应用”的迁移）
• 第三步：团队同步更新代码，避免其他人重新生成相同迁移
• ? 提示：生产环境强烈建议用新迁移来“反向修正”，而非回滚——更可控、可审计

基本上就这些。回滚本身不复杂，但容易忽略数据库状态与迁移文件的一致性。记住口诀：先动库，再动码；没执行，才能删。