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"))）
基本上就这些。迁移不是黑盒魔法，而是可控的契约——模型变，迁移跟；脚本审，上线稳；历史清，协作顺。
