迁移是EF Core数据库版本控制机制，通过add-migration生成Up/Down方法脚本，update-database执行并记录至__EFMigrationsHistory表；开发中需及时生成、检查脚本、避免冲突；生产环境应导出SQL交DBA审核，禁用业务逻辑；注意重命名、多上下文等特殊处理，确保演进可控。
Entity Framework Core 的迁移（Migrations）本质上是数据库架构的版本控制机制——它把模型变更记录为可执行、可回滚、可协作的代码文件，让团队能在不同环境（开发、测试、生产）中一致地演进数据库结构。
迁移如何工作：从模型到 SQL 脚本
当你修改了 C# 中的实体类或 DbContext 配置（比如新增一个属性、改字段类型、加外键），EF Core 不会自动同步数据库。你需要显式创建迁移：
-
add-migration 命令分析当前模型与上一次迁移快照（
ModelSnapshot）的差异，生成一对 C# 文件（Up()和Down()方法） -
Up()包含将数据库升级到新版本的 SQL 操作（如ALTER TABLE、CREATE INDEX） -
Down()是逆向操作，用于回退（但某些变更如删列、改类型可能无法完全还原，需手动调整） - 执行 update-database 后，EF Core 在
__EFMigrationsHistory表中记录已应用的迁移 ID，作为“数据库当前版本”的依据
日常开发中的关键实践
避免迁移冲突和不可控变更，需遵守几个轻量但重要的习惯：
- 每次功能开发完成、模型定稿后立即生成迁移，不要积压多个改动再统一生成（否则 diff 易出错，
Down()逻辑难维护） - 生成迁移前先运行 dotnet ef migrations remove（或
Remove-Migration）撤回未提交的本地迁移，尤其在拉取他人代码后发现迁移冲突时 - 检查生成的迁移文件内容——确认 SQL 是否符合预期（例如是否误删了重要列、索引是否加在正确字段上），必要时手工编辑
Up()/Down() - 团队共享迁移文件（.cs + .Designer.cs + .resx），它们是源码的一部分，必须提交到 Git
处理生产环境的迁移安全策略
生产库不能直接跑 update-database，应导出 SQL 脚本交 DBA 审核：
- 用 dotnet ef migrations script（或
Script-Migration）生成完整或区间脚本，例如：dotnet ef migrations script 20231001000000_Initial 20240515120000_AddUserStatus - 脚本默认包含事务包裹，失败则整体回滚；也可加
--no-transactions适配不支持 DDL 事务的数据库（如 MySQL 旧版本） - 避免在迁移中写业务逻辑（如
Sql("UPDATE ...")），这类操作难以测试、易出错；应拆到部署后的种子脚本或发布任务中
常见陷阱与绕过技巧
有些场景 EF Core 默认行为不够灵活，需要干预：
-
重命名列/表：EF Core 6+ 支持
HasColumnName("OldName").HasColumnName("NewName")并自动生成sp_rename或RENAME COLUMN，但老版本需手动在迁移里写原生 SQL -
初始迁移已有数据库：先用
dotnet ef migrations add InitialCreate --skip-runtime创建空迁移，再运行dotnet ef migrations add InitialCreate -o Migrations/InitialCreate --idempotent生成幂等脚本，最后用update-database标记历史表已存在 -
多 DbContext 共享库：每个上下文需独立的迁移文件夹（
-o指定路径）和历史表名（UseSqlServer(..., o => o.MigrationsHistoryTable("__MyAppHistory"))）
基本上就这些。迁移不是黑盒魔法，而是可控的契约——模型变，迁移跟；脚本审，上线稳；历史清，协作顺。
