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 这里断掉。
