EF Core 默认使用 dbo.__EFMigrationsHistory 表记录迁移状态，可通过 MigrationsHistoryTable 方法自定义表名和模式；替换 IHistoryRepository 可修改列名；添加审计字段需手动执行 SQL 增列并设默认值；配置后需验证表名、字段及迁移写入是否生效。

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() 注册
• 注意：列名变更后，所有环境必须同步更新，否则迁移命令会报错

添加审计字段（如 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。