SaveChangesAsync仅首次执行成功，后续报错：无法插入Message表标识列显式值

这问题我之前帮同事排查过几乎一模一样的场景，结合你提到的现象（重启服务恢复、Id是标识列、程序自动生成值），大概率是ORM上下文缓存/会话级配置残留导致的，给你拆解几个核心排查方向和解决办法：

1. 检查ORM上下文的生命周期配置 #

如果你的DbContext被注册成了单例（比如ASP.NET Core里用AddSingleton），那跨请求复用的上下文很可能会出现元数据缓存异常：首次请求时映射正确，后续请求因为上下文被多线程修改或者缓存逻辑异常，错误地把Id列当成了需要手动插入的普通列。

解决办法：确保DbContext是请求级别的生命周期，比如ASP.NET Core里用默认的AddDbContext（底层是Scoped），或者手动指定AddScoped：

// 正确的注册方式（ASP.NET Core 6+）
builder.Services.AddDbContext<YourDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

2. 对比Profiler中首次成功和后续失败的SQL语句 #

你已经用SQL Server Profiler调试了，一定要重点对比两次的INSERT语句：

• 如果失败的SQL里明确包含了Id列（比如INSERT INTO Message (Id, Content, ...) VALUES (@p0, @p1, ...)），那说明ORM在后续请求里错误地生成了包含标识列的插入语句。

这时候要检查实体类的映射配置是否正确：

数据注解方式 #

public class Message
{
    [Key]
    // 必须明确指定是数据库生成的标识列
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int Id { get; set; }
    
    public string Content { get; set; }
    // 其他属性...
}

Fluent API方式 #

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Message>()
        .Property(m => m.Id)
        .ValueGeneratedOnAdd(); // 等价于标识列配置
}

3. 排查是否有IDENTITY_INSERT未关闭的情况 #

如果你的代码里有特殊场景（比如批量导入、数据恢复）手动开启了SET IDENTITY_INSERT Message ON;，但执行完后没有关闭SET IDENTITY_INSERT Message OFF;，那么这个数据库会话会被连接池复用，后续所有用这个会话的插入请求都会报错，直到连接被回收或者服务重启。

解决办法：检查所有涉及Message表的批量操作代码，确保开启IDENTITY_INSERT后必关闭，最好用try/finally包裹：

SET IDENTITY_INSERT Message ON;
BEGIN TRY
    -- 执行插入操作
    INSERT INTO Message (Id, Content) VALUES (1, 'Test');
END TRY
BEGIN CATCH
    -- 异常处理
END CATCH
SET IDENTITY_INSERT Message OFF; -- 必须执行，避免会话污染

4. 排除线程安全问题 #

如果你的代码里存在多线程共享同一个DbContext实例的情况，很可能会破坏上下文的元数据映射，导致后续请求生成错误的SQL。一定要记住：DbContext不是线程安全的，每个请求/操作都应该使用独立的上下文实例。

内容的提问来源于stack exchange，提问作者t3chb0t