EF Core 迁移支持通过 MigrationBuilder 执行自定义 SQL 和结构操作，并可通过扩展方法封装复用逻辑；需分离结构变更与数据填充，确保 Down 可逆、不依赖运行时服务、兼顾多数据库兼容性与幂等性。
EF Core 的迁移默认生成标准的 CREATE TABLE、ALTER COLUMN 等 SQL 操作，但实际项目中常需执行自定义逻辑，比如添加索引、执行数据转换、调用存储过程或修改约束。这时就要用到 MigrationBuilder 提供的扩展能力。
直接使用 MigrationBuilder 的内置方法
MigrationBuilder 在 Up(MigrationBuilder migrationBuilder, ……) 和 Down(MigrationBuilder migrationBuilder, ……) 中可用，它已封装常用操作：
migrationBuilder.Sql("UPDATE Users SET Status = 1 WHERE CreatedAt —— 执行任意 SQL（注意：生产环境慎用，需确保幂等性）-
migrationBuilder.CreateIndex("IX_Users_Email", "Users", "Email", unique: true);—— 创建唯一索引 -
migrationBuilder.DropIndex("IX_Orders_Status", "Orders");—— 删除索引 -
migrationBuilder.AlterColumn—— 修改列可空性("Description", "Products", nullable: true, oldNullable: false); -
migrationBuilder.RenameColumn("OldName", "Table", "NewName");—— 重命名列（部分数据库支持，如 SQL Server；SQLite 需手动模拟）
编写可复用的自定义扩展方法
为避免重复写 SQL 或提升可读性，可为 MigrationBuilder 添加静态扩展方法：
public static class MigrationBuilderExtensions {public static void AddSoftDeleteConstraint(this MigrationBuilder migrationBuilder, string tableName) {migrationBuilder.Sql($@"ALTER TABLE {tableName} ADD CONSTRAINT CK_{tableName}_IsDeleted CHECK (IsDeleted IN (0, 1));"); } }然后在迁移中直接调用：migrationBuilder.AddSoftDeleteConstraint("Users");
这类扩展适合团队统一规范，比如自动添加软删除检查、时间戳默认值、或租户字段约束。
在迁移中安全处理数据变更
结构变更（如加列）和数据填充不能混为一谈。EF Core 不自动处理“已有数据如何初始化”，需手动补全：
- 新增非空列时，先用
nullable: true添加，再Sql()更新旧数据，最后AlterColumn(…… nullable: false) - 用
HasData()配置种子数据仅影响首次迁移；若需更新已有记录，必须在Up()中用Sql()或分步InsertData/UpdateData - 对大表执行
UPDATE建议加WHERE条件并分批，避免锁表过久
避免常见陷阱
自定义迁移不是写脚本的自由区，几个关键点要守住：
- Down 方法必须可逆：如果
Up中执行了Sql("DROP TABLE")，Down就得重建表结构 + 恢复数据（通常不现实），应改用保留字段、视图或标记删除 - 不要依赖运行时服务 ：迁移在设计时执行，
DbContext实例、DI 容器、配置对象均不可用；所有参数需硬 编码 或从迁移参数传入 - 跨数据库兼容性：
Sql()语句可能只适用于 SQL Server，换 SQLite 或 PostgreSQL 就报错；多提供者项目建议用条件分支或单独迁移集 - 幂等性优先：生产环境脚本常被多次执行，
IF NOT EXISTS、CREATE OR REPLACE等写法更稳妥（注意 EF Core 默认不生成这些）
基本上就这些。自定义迁移不复杂但容易忽略上下文限制，重点是把结构变更和数据逻辑分开想，再用 Sql() 或扩展方法稳住关键环节。
