ef core 7 官方不支持 oracle 数据库的全局查询筛选器（hasqueryfilter），因其 provider 缺失 sql 生成逻辑，导致过滤条件不注入 sql；替代方案是应用层封装扩展方法（如 activeusers）强制过滤。
EF Core 7 官方不支持 Oracle 数据库的全局查询筛选器（HasQueryFilter）——不是配置错，而是根本不会生效。 Oracle 提供的 Oracle.EntityFrameworkCore（截至 2026 年 10 月最新版为 7.21.0）仍缺失对查询筛选器的 SQL 生成支持。你写了 HasQueryFilter，编译通过、运行无报错，但生成的 SQL 里压根不包含那个过滤条件。
为什么 Oracle Provider 不处理 HasQueryFilter
EF Core 的全局筛选器依赖数据库提供程序在翻译 LINQ 表达式时主动注入 WHERE 子句。SQL Server、PostgreSQL、SQLite 等 provider 都实现了这一步；但 Oracle provider 的查询翻译器至今未覆盖 HasQueryFilter 对应的表达式节点。它会静默跳过该逻辑，既不报错也不警告。
- 你可以用
DbContext.Database.Log或 Oracle 性能视图（如V$SQL）验证：执行context.Users.ToList()，SQL 日志里看不到类似WHERE "IsDeleted" = 0的片段 - EF Core 源码中
OracleQuerySqlGenerator类没有重写VisitFilter方法，这是关键缺失点 - 这不是“没文档”或“配置姿势不对”，而是 provider 功能缺口
替代方案：手动封装 + 扩展方法模拟全局过滤
既然框架层不支持，就退到应用层补位。核心思路是：把 DbSet<t></t> 包一层，让所有业务查询都走可控入口，而不是直接暴露原始 DbSet。
- 定义扩展方法，例如：
public static IQueryable<user> ActiveUsers(this DbSet<user> set) => set.Where(u => !u.IsDeleted);</user></user> - 在 DbContext 中只暴露封装后的方法：
public IQueryable<user> Users => Set<user>().ActiveUsers();</user></user>（注意返回类型是IQueryable<user></user>，不是DbSet<user></user>） - 需要查全部（含已删除）时，才调用
Set<user>()</user>原始访问器 —— 这种场景本就该显式标记，比如叫AllUsersRaw() - 多租户场景同理：加
TenantId字段后，写ForTenant(int tenantId)扩展，强制所有查询带租户约束
如果硬要用 HasQueryFilter，会发生什么
代码能跑，但数据不安全 —— 这是最危险的情况。
- 你在
OnModelCreating里写了modelBuilder.Entity<user>().HasQueryFilter(u => !u.IsDeleted)</user> - 所有
context.Users.Where(...)看似“自动过滤”，实则全量查出再内存过滤（EF Core 回退到客户端评估） - Oracle 表数据量稍大（比如 >5k 行），就会触发
Microsoft.EntityFrameworkCore.Query.ClientEvalWarning警告，且性能断崖下跌 - 更糟的是：延迟加载（
Include）、AsNoTracking()下，这个客户端过滤可能被意外绕过，导致已删除数据泄露
真正要落地软删除或多租户，别寄希望于 Oracle provider “哪天突然支持”。现在就得靠封装 + 代码约定守住边界，否则上线后查不到 bug，只查得到脏数据。
