Entity Framework Core 5在SQL Server单元测试中遭遇自增ID插入失败后级联删除异常问题

嘿，这个问题我之前在做EF Core 5的单元测试时也踩过一模一样的坑！让我来帮你理清楚到底发生了什么，以及怎么解决它。

问题根源：EF Core的变更追踪“残留” #

你遇到的核心问题其实和数据库级联删除本身无关，而是EF Core的内存变更追踪机制在搞鬼：

• 当你尝试插入子实体失败后，虽然数据库里没有这条数据，但你的DbContext内存中仍然保留着这个子实体的追踪记录，并且它的状态是Added（因为你调用了Add方法）。
• 当你删除父实体时，EF Core会自动处理关联的子实体（因为配置了级联删除）。但对于这条状态为Added的子实体，EF的逻辑会认为：“这个实体应该存在于数据库里，现在要级联删除它，得先确保它被插入？”——这就触发了和之前一样的IDENTITY_INSERT错误，哪怕你根本没打算插入它。

解决办法 #

这里有几个可行的方案，按优先级排序：

1. 清理失效的实体追踪（最快临时解决） #

在子实体插入失败后，把它从DbContext的追踪中移除：

// 假设你的子实体变量是failedChild
context.Entry(failedChild).State = EntityState.Detached;

这样EF就不会再管这个实体了，删除父实体时也就不会触发多余的操作。

2. 单元测试用独立DbContext（最佳实践） #

单元测试中最容易踩的坑就是复用DbContext导致状态污染。正确的做法是每个测试方法都使用全新的DbContext实例，比如用using包裹：

[Fact]
public async Task TestDeleteParentAfterFailedInsert()
{
    // 每个测试都新建DbContext，彻底隔离状态
    using var context = new YourDbContext();

    // 插入父实体
    var parent = new Parent { Name = "Test Parent" };
    context.Parents.Add(parent);
    await context.SaveChangesAsync();

    // 尝试插入子实体（显式设Id）
    var child = new Child { Id = 999, ParentId = parent.Id, Name = "Test Child" };
    context.Children.Add(child);
    bool insertFailed = false;
    try
    {
        await context.SaveChangesAsync();
    }
    catch (DbUpdateException)
    {
        insertFailed = true;
    }
    Assert.True(insertFailed);

    // 现在删除父实体，因为是新的DbContext，没有残留的子实体追踪
    context.Parents.Remove(parent);
    await context.SaveChangesAsync();

    // 验证父实体已被删除
    var deletedParent = await context.Parents.FindAsync(parent.Id);
    Assert.Null(deletedParent);
}

3. 必要时开启IDENTITY_INSERT（如果确实需要显式设Id） #

如果你确实有场景需要给自增列显式赋值，那要先在数据库层面开启IDENTITY_INSERT，操作完再关闭：

// 开启IDENTITY_INSERT
await context.Database.ExecuteSqlRawAsync("SET IDENTITY_INSERT [XXXXX] ON;");

// 执行插入操作
context.Children.Add(child);
await context.SaveChangesAsync();

// 关闭IDENTITY_INSERT
await context.Database.ExecuteSqlRawAsync("SET IDENTITY_INSERT [XXXXX] OFF;");

注意：这个操作是针对整个表的，所以要确保在多线程场景下不会有冲突，单元测试里用的话问题不大。

总结 #

本质上就是EF的内存追踪状态和数据库实际状态不一致导致的问题。只要清理掉失效的追踪记录，或者用干净的DbContext，就能解决这个诡异的错误。

内容的提问来源于stack exchange，提问作者Marc-Arthur