EF Core 的级联删除不是自动开启的，它依赖于模型配置和数据库行为的协同。关键在于：你得在
OnModelCreating里用
OnDelete(DeleteBehavior.Cascade)明确声明，同时确保数据库外键也启用了
ON DELETE CASCADE—— 否则只靠 EF Core 模型配置，在子实体未被加载进内存时，删除可能失败或报约束异常。
级联删除生效的两个必要条件
EF Core 的级联逻辑分两层：应用层（DbContext）和数据库层。缺一不可。
模型配置必须显式启用：仅靠外键字段为非空（必选关系），EF Core 默认行为不一定是Cascade（尤其在较新版本中，默认可能是
Restrict或
ClientNoAction） 数据库外键需同步支持：EF Core 迁移生成的外键约束，只有在调用
dotnet ef migrations add+
update-database后，才会把
ON DELETE CASCADE写入数据库。若手动建库或跳过迁移，这层会缺失
如何正确配置 OnDelete Cascade
在
OnModelCreating中对一对多关系设置是最常见方式：
modelBuilder.Entity<Parent>()
.HasMany(p => p.Children)
.WithOne(c => c.Parent)
.HasForeignKey(c => c.ParentId)
.OnDelete(DeleteBehavior.Cascade);
注意三点：
必须是 必选关系（ParentId不可为空），否则
Cascade不合法；可选关系应考虑
SetNull或软删除
WithOne(c => c.Parent)中的导航属性名要与子实体实际属性名一致，否则配置无效 如果子实体已存在数据，修改配置后需重新迁移，否则旧外键不会自动更新
级联删除的实际触发时机
EF Core 只在以下情况真正执行级联逻辑：
你调用context.Parents.Remove(parent)并
SaveChanges()且该
parent实体被上下文跟踪（比如是从数据库查出来的） 或即使没被跟踪，但数据库外键已设
ON DELETE CASCADE，此时数据库自行完成子记录清理
反例：直接 new 一个 Parent 实体并 Remove，EF Core 不知道它有没有子项，也不会去查——这时全靠数据库外键兜底。
替代方案：避免物理级联的常用做法
生产环境多数不推荐纯物理级联删除，更倾向可控、可审计的方式：
软删除标记：加IsDeleted字段 + 全局查询过滤器 + 自定义
ExecuteDelete批量标记 ExecuteDelete 批量清理：EF Core 7+ 支持
context.Children.Where(c => c.ParentId == id).ExecuteDelete()，高效且不加载数据 仓储层封装逻辑：在 Repository 中先删子，再删父，显式控制顺序和事务边界
基本上就这些。配置不复杂，但容易忽略数据库层是否真正生效。
