在Entity Framework Core中，实体之间的关系通常通过外键来约束。当主表记录被删除时，从表里依赖它的数据应当如何处理，需要在模型构建阶段就明确规划。EF Core提供的 OnDelete 方法与 DeleteBehavior 枚举是控制级联删除行为的核心入口。很多人只配置了 Cascade 就执行迁移，结果在SQL Server中遇到循环级联路径错误，根本原因在于没有区分不同删除行为在数据库层与客户端跟踪层之间的实际差异。
DeleteBehavior枚举值与底层数据库差异
EF Core中的 DeleteBehavior 枚举包含多个选项，最常用的有 Cascade、ClientSetNull、Restrict 以及 SetNull。Cascade 表示删除主实体时，数据库直接删除所有关联的从实体，这会在外键约束上生成 ON DELETE CASCADE。ClientSetNull 则不同，它要求EF Core先在内存中把依赖实体的外键属性置为 null，再由上下文发送更新命令，数据库本身并不建立级联删除。Restrict 禁止任何自动删除或置空操作，如果存在关联数据，删除主体会抛出数据库异常。而 SetNull 介于两者之间，由数据库在删除主体时把外键更新为 null，仅适用于外键列可空的关系。
从迁移脚本的角度看，Cascade 会在 CreateTable 或 AddForeignKey 语句中显式写出 onDelete: ReferentialAction.Cascade；而 ClientSetNull 在SQL Server提供程序下通常生成 ON DELETE NO ACTION，真正的置空逻辑落在EF Core的 ChangeTracker 里。如果使用 ClientSetNull 但上下文中没有正确跟踪从实体，外键就不会被更新，保存时可能触发数据库非空约束错误。理解这一差异，是避免迁移后出现意外数据残留或运行时异常的前提。
下面通过Fluent API代码展示博客与文章的一对多关系如何配置不同的删除行为：
// 博客与文章为一对多关系，文章依赖博客
modelBuilder.Entity<Blog>()
.HasMany(b => b.Posts)
.WithOne(p => p.Blog)
.HasForeignKey(p => p.BlogId)
.OnDelete(DeleteBehavior.Cascade); // 主表删除时从表跟随删除
// 另一种可选配置，由客户端置空外键
modelBuilder.Entity<Blog>()
.HasMany(b => b.Posts)
.WithOne(p => p.Blog)
.HasForeignKey(p => p.BlogId)
.OnDelete(DeleteBehavior.ClientSetNull);
Fluent API、数据注解与默认约定的关系
除了Fluent API，EF Core也支持通过数据注解来影响关系，但必须注意 Required 与 Optional 特性会间接改变默认删除行为。按照EF Core的约定，如果关系是必需的，即外键属性为非可空类型或标记了 Required，那么SQL Server提供程序下的默认删除行为是 Cascade；如果外键可空，属于可选关系，默认删除行为则是 ClientSetNull。这意味着即使不写 OnDelete，只要实体结构决定了必填，框架也会尝试建立级联删除。
使用数据注解时，通常通过 ForeignKey 特性指定外键属性，但数据注解本身并没有直接对应 DeleteBehavior 的属性，因此删除行为仍然建议在 OnModelCreating 中统一设置。如果完全依赖约定，当外键从非可空改为可空时，级联删除会悄然变为客户端置空，可能在后续运行中产生数据残留或逻辑不一致。正因如此，团队项目更推荐显式调用 OnDelete，避免因模型微调导致删除策略发生变化。
以下示例展示了一个可选关系，以及如何通过代码覆盖默认的 ClientSetNull：
public class Post
{
public int Id { get; set; }
// 外键可空，默认为可选关系
public int? BlogId { get; set; }
public Blog Blog { get; set; }
}
// 在上下文里显式改为级联，覆盖默认ClientSetNull
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Post>()
.HasOne(p => p.Blog)
.WithMany(b => b.Posts)
.HasForeignKey(p => p.BlogId)
.OnDelete(DeleteBehavior.Cascade);
}
循环级联、性能优化与安全删除策略
最典型的坑是多条外键关系形成循环级联路径。例如订单依赖客户，订单项依赖订单，同时客户又通过另一张表间接依赖订单项，SQL Server不允许同一条删除语句经过多个级联路径到达同一张表，迁移会直接失败。遇到这种情况，必须把其中某些关系改为 ClientSetNull 或 Restrict，由应用层分批删除相关记录。另一个常见问题是大量子表数据触发级联时，数据库可能锁住多张表造成阻塞，此时应优先考虑在应用层分页删除从表，再删除主表。
从性能角度看，Cascade 由数据库原生执行，通常比客户端先加载再逐条删除更快，但它不受EF Core拦截器控制，审计日志难以捕获从表删除动作。如果业务要求记录谁删除了文章及其下属评论、图片等，就应使用 Restrict，在服务层先查询关联数据再手动删除，并把操作写入日志表。此外，单元测试中建议使用内存数据库或与实际提供程序一致的类型来验证 OnDelete 配置，因为不同数据库提供程序对 DeleteBehavior 的映射略有差异，例如SQLite对循环级联的容忍度与SQL Server不同。
下面代码展示了在应用层安全删除博客并处理级联禁止情况时的基本思路：
public async Task DeleteBlogSafeAsync(int blogId)
{
var blog = await _context.Blogs.FindAsync(blogId);
if (blog == null) return;
// 若配置为Restrict，需手动移除关联文章
var posts = _context.Posts.Where(p => p.BlogId == blogId);
_context.Posts.RemoveRange(posts);
_context.Blogs.Remove(blog);
try
{
await _context.SaveChangesAsync();
}
catch (DbUpdateException ex)
{
// 记录日志或执行补偿逻辑
throw new InvalidOperationException("删除博客时级联处理失败", ex);
}
}
总体而言，EF Core的级联删除行为并不是单纯设置一个 Cascade 就能一劳永逸。开发者需要根据关系是否可选、数据库提供程序的实现差异以及业务审计需求，综合选择 Cascade、ClientSetNull、Restrict 或 SetNull。显式配置 OnDelete 可以避免默认约定在模型演进时带来的隐性变化，同时配合应用层手动删除与异常补偿，能够让数据删除过程更加可控、安全。在实际项目中，建议把删除策略作为数据访问层设计的一部分提前评审，而不是等到迁移失败或出现数据残留时再补救。