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<string>("Description", "Products", nullable: true, oldNullable: false);</string> —— 修改列可空性
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()或扩展方法稳住关键环节。
