在使用Entity Framework Core构建数据访问层时，实体之间的关系往往通过外键进行约束。当我们需要在主表记录被移除时，自动清理掉从表中依赖它的数据，就必须弄明白EF Core提供的级联删除机制。OnDelete方法是Fluent API里专门用来设置这一行为的关键入口，它接收一个DeleteBehavior枚举值，决定当主体被删除时依赖项如何处理。很多人在初次接触时只设置了Cascade，却在运行迁移时发现数据库报出循环级联路径错误，根本原因就是对不同行为在SQL Server等数据库中的实际生成语句缺乏认识。
OnDelete的可选行为及底层差异
EF Core中的DeleteBehavior枚举包含多个值，最常用的有Cascade、ClientSetNull、Restrict以及SetNull。Cascade表示当主实体删除时，所有关联的从实体也由数据库直接删除，这在SQL层面会生成ON DELETE CASCADE的外键约束。ClientSetNull则比较特殊，它要求EF Core在内存中先把关联的外键置为null，然后再由上下文发送更新或删除命令，数据库本身并不设置级联删除。Restrict会禁止任何自动操作，如果还存在关联数据，删除主体将直接抛出异常。
从实际迁移脚本来看，Cascade会在迁移的CreateTable或AddForeignKey语句中显式写出onDelete: ReferentialAction.Cascade，而ClientSetNull在SQL Server中通常生成ON DELETE NO ACTION，真正的置空逻辑落在EF Core的ChangeTracker里。理解这一点非常重要，因为如果使用ClientSetNull但上下文没有正确跟踪从实体，那么外键就不会被更新，进而在保存时触发数据库非空约束错误。SetNull与ClientSetNull类似，但数据库层会主动把外键设为null，仅适用于外键列可为空的关系。
下面通过一段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，EF Core也支持使用数据注解来影响关系，但必须注意Required与Optional特性会间接改变默认删除行为。按照EF Core约定，如果关系是必需的（如外键属性是非可空类型且标记了Required），那么默认删除行为在SQL Server提供程序下是Cascade；如果是可选的（外键可空），默认是ClientSetNull。这意味着你即使不写OnDelete，只要实体结构决定了必填，框架也会尝试建立级联删除。
使用数据注解时，我们通常用ForeignKey特性指定外键，但删除行为仍建议在OnModelCreating里统一设置，因为注解本身没有直接对应DeleteBehavior的属性。如果强行依赖约定，当后期把外键改为可空，级联就会悄然变为客户端置空，可能引发生产环境的数据残留。因此团队项目中更推荐显式调用OnDelete，避免约定随模型微调而漂移。
以下示例展示了一个可选关系下约定产生的默认行为，以及如何用代码覆盖：
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不同。
最后给出一段在应用层安全删除并处理级联禁止情况的代码，展示如何结合SaveChanges的异常做补偿：
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);
}
}