ef core软删除必须配合hasqueryfilter全局查询过滤器才能生效，仅添加isdeleted属性无效；字段须为非空bool类型并默认false；临时绕过需用ignorequeryfilters()且需对每个实体单独调用；硬删除前应确保已软删除并封装在服务层。
EF Core 软删除必须配合全局查询过滤器，否则 IsDeleted 字段形同虚设
软删除不是靠约定或命名自动生效的。EF Core 不会因为你加了 IsDeleted 属性就自动跳过被标记的记录——它只会在你显式写 .Where(x => !x.IsDeleted) 时才起作用。真正让软删除“全局生效”的，是 HasQueryFilter。漏掉这一步，后续所有查询（包括导航属性加载、Include、Find）都可能意外查出已“删除”的数据。
实操建议：
- 在
OnModelCreating中为每个需要软删除的实体调用HasQueryFilter，例如：modelBuilder.Entity<order>().HasQueryFilter(x => !x.IsDeleted);</order>
- 如果实体使用了继承（如
BaseEntity），可统一用泛型方式批量注册，避免重复写；但注意：基类不能是抽象类且需被映射到具体表，否则过滤器不生效 - 过滤器表达式必须是可翻译成 SQL 的纯 LINQ 表达式，不能调用本地方法或访问非映射属性
软删除字段类型和默认值必须与查询过滤器严格一致
常见错误是定义 IsDeleted 为 bool?（可空布尔），但过滤器写成 !x.IsDeleted，结果生成的 SQL 是 WHERE [IsDeleted] != 1，而 NULL 值永远不满足该条件，导致这些记录被永久“隐藏”且无法通过常规查询恢复。
正确做法：
- 字段类型必须是
bool（非可空），数据库列设为NOT NULL DEFAULT 0 - 实体构造函数中显式初始化：
public class Product { public bool IsDeleted { get; set; } = false; } - 迁移命令生成后，检查
Up(MigrationBuilder)中是否包含defaultValue: false，缺失则手动补上
需要临时绕过软删除时，用 IgnoreQueryFilters()，但别滥用
后台管理、回收站、审计等场景确实需要查全部数据（含已删）。此时不能删掉全局过滤器再重建上下文，而是用 IgnoreQueryFilters() 临时关闭：
var allOrders = context.Orders.IgnoreQueryFilters().ToList();
注意风险点：
-
IgnoreQueryFilters()影响整个查询链，包括后续的Include导航属性，若关联实体也有软删除过滤器，它们**不会自动被忽略**——必须对每个实体分别调用 - 绝不应在 Web API 普通接口中无条件使用它，否则软删除策略彻底失效
- 如果只是想“查某个 ID 是否存在（不管删没删）”，优先用
FindAsync+AsNoTracking，它本身不应用查询过滤器
硬删除前务必先取消软删除标记，或改用专用服务封装逻辑
用户点击“彻底删除”时，直接调用 context.Remove(entity) 是危险的：EF Core 会尝试物理删除，但数据库可能因外键约束或触发器失败；更糟的是，如果该实体已被软删除，你本意是清理数据，结果却抛出异常或误删关联行。
推荐方案：
- 提供明确的
HardDeleteAsync(T entity)方法，在其中先context.Entry(entity).State = EntityState.Modified，更新IsDeleted = true（确保已是软删状态），再执行物理删除 - 或者更稳妥：只允许从回收站发起硬删除，并校验
IsDeleted == true后再Remove - 所有删除操作必须走服务层，禁止 Controller 直接调用
Remove或裸写SaveChanges
软删除真正的复杂点不在配置，而在业务语义的贯穿——从数据库约束、API 响应体字段、前端按钮状态，到定时任务清理逻辑，IsDeleted 必须作为一等公民参与全程决策，而不是一个贴在实体上的装饰标签。
