EF Core 默认使用
__EFMigrationsHistory表（位于
dbo模式下）记录迁移执行状态，但你可以通过配置轻松自定义它的名称、模式，甚至字段结构——关键在于用对方法，避免直接改表引发一致性风险。
修改表名和数据库模式
这是最常用也最安全的自定义方式，只需在
OnConfiguring中调用
MigrationsHistoryTable： 指定新表名和 Schema（模式），例如改为
audit.__Migrations代码示例：
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(connectionString, x =>
x.MigrationsHistoryTable("__Migrations", "audit"));
}
首次运行 dotnet ef database update时，EF Core 会自动创建该表；已有迁移历史需手动迁移数据或清空重来
替换列名（如 MigrationId → Id）
默认字段名不满足命名规范？可通过替换
IHistoryRepository实现： 新建继承自
SqlServerHistoryRepository的类，重写
ConfigureTable方法 在
OnConfiguring中用
.ReplaceService<ihistoryrepository customhistoryrepository>()</ihistoryrepository>注册 注意：列名变更后，所有环境必须同步更新，否则迁移命令会报错
添加审计字段（如 AppliedAt、AppliedBy）
EF Core 不允许直接扩展历史表结构，但可安全增强：
先让 EF Core 创建默认历史表（或自定义表名） 再用 SQL 手动添加非空字段（建议设默认值，如GETDATE()） 配合数据库触发器或应用层逻辑，在每次插入时填充操作人等信息 不推荐删改原生字段，只建议增列
查看与验证配置是否生效
配置完别急着跑迁移，先确认效果：
执行dotnet ef migrations list，检查输出中是否提示“Using migration history table 'xxx' in schema 'yyy'” 连接数据库，查表是否存在、字段是否符合预期：
SELECT TOP 1 * FROM [audit].[__Migrations]运行一次
dotnet ef database update，观察是否成功写入新表
基本上就这些。改名改模式很稳妥，改字段要绕点路但可控，直接删记录或改主键结构则容易出问题——优先走配置，少碰裸 SQL。
