EF Core 多租户无内置支持，需按场景权衡：Database-per-Tenant（物理隔离、高安全）、Schema-per-Tenant（逻辑隔离、易维护）、Row-level Filtering（轻量但需严格审查），核心是租户上下文早于 DbContext 创建并贯穿请求链路。

EF Core 本身不内置多租户支持，但可以通过多种方式实现数据隔离，核心在于请求上下文感知 + 查询拦截 + 模型配置。关键不是“选哪种方案”，而是根据租户规模、隔离强度、运维成本和现有架构来权衡。

按数据库隔离（Database-per-Tenant）

每个租户独占一个数据库，物理级隔离，安全性最高，扩展性好，适合 SaaS 中大型客户或合规要求严的场景。

• 连接字符串需动态生成，通常从 HTTP 上下文（如 Host 头、路由、Token 声明）提取租户标识
• 在 IDbContextFactory 或自定义 DbContext 构造时传入租户 ID，拼接出对应连接字符串
• 注意连接池管理：不同租户数据库不能共用连接池，EF Core 默认会按连接字符串区分，无需额外处理
• 迁移需为每个租户单独执行（可用 dotnet ef migrations script + 脚本分发，或运行时调用 MigrateAsync()）

按 Schema 隔离（Schema-per-Tenant）

所有租户共享同一数据库，但各自拥有独立 Schema（如 PostgreSQL/SQL Server），逻辑隔离，兼顾安全与维护效率。

• 在 OnModelCreating 中通过 entity.ToTable("Users", tenantSchemaName) 统一指定 Schema
• 确保每次 DbContext 实例化时已知租户 Schema 名（可从依赖注入容器中解析 ITenantContext）
• 建库脚本或迁移需支持创建 Schema（SQL Server 可用 CREATE SCHEMA；PostgreSQL 自动支持）
• 注意：SQL Server 中 DefaultSchema 是全局设置，无法 per-context 覆盖，必须显式调用 ToTable(..., schema)

按数据行过滤（Row-level Filtering）

所有租户数据混存在同一张表，靠查询自动附加 TenantId == current 条件，开发最轻量，但依赖严格审查，适合内部系统或租户间无强隔离需求的场景。

• 使用全局查询过滤器（Global Query Filters）：modelBuilder.Entity().HasQueryFilter(x => x.TenantId == _tenantService.GetCurrentTenantId())
• _tenantService 必须是 Scoped 生命周期，且在 Filter 中不能直接注入（EF Core 不支持），应改用 DbContext 构造函数传入或通过 IServiceProvider 解析（推荐前者）
• 敏感操作（如后台任务、管理员视图）需临时禁用过滤器：context.Set().IgnoreQueryFilters()
• 索引建议：为 TenantId 字段建立复合索引（如 (TenantId, CreatedAt)），避免全表扫描

租户识别与上下文注入要点

无论采用哪种隔离方式，租户识别必须早于 DbContext 创建，且线程/请求安全。

• 常见识别源：JWT Token 中的 tenant_id、子域名（acme.example.com）、请求头（X-Tenant-ID）、API Key 查表
• 在 ASP.NET Core 中，通过 AddScoped() 注入，并在中间件中解析并填充租户信息
• DbContext 应声明为 Scoped，且构造函数接收 ITenantContext 或其关键值（如 string TenantId），避免在 OnConfiguring 中延迟解析
• 避免静态缓存租户信息——跨请求复用会导致数据错乱

基本上就这些。没有银弹，Database-per-Tenant 最稳，Row-level 最省事，Schema-per-Tenant 是平衡之选。实际项目中常混合使用（比如核心租户表用 DB 隔离，日志类表用行过滤）。关键是把租户上下文流透整个请求链路，别让它在 DbContext 这里断掉。