ef core 支持多 dbcontext，应按业务域划分、各司其职；分别注册、独立配置连接字符串与 onmodelcreating；跨库查询需应用层组合；迁移须显式指定上下文并隔离目录。
EF Core 支持一个应用中使用多个 DbContext，常见于微服务拆分、读写分离、多租户或不同业务模块隔离等场景。关键不是“能不能”，而是“怎么设计得清晰、不冲突、易维护”。
按业务域划分多个 DbContext
每个 DbContext 应聚焦单一职责，比如订单上下文只管订单、支付上下文只管支付，避免一个上下文映射几十张表。这样迁移、测试、升级都更可控。
- 为每个上下文定义独立的类，继承
DbContext - 在
Startup.cs或Program.cs中分别注册，指定不同连接字符串和生命周期（通常用AddDbContext<tcontext></tcontext>多次调用） - 每个上下文的
OnModelCreating只配置自己负责的实体，不交叉
连接字符串与数据库隔离
多个上下文默认可指向不同数据库（甚至不同数据库类型），只要连接字符串和 Provider 配置正确。
- 在
appsettings.json中配置多个连接字符串，如OrderDbConnection、ProductDbConnection - 注册时通过
options.UseSqlServer(...)或options.UseNpgsql(...)指定对应连接字符串 - 注意：不同上下文之间不能直接跨库做 LINQ Join（除非数据库原生支持，如 SQL Server 的四部分名称），需应用层组合数据
依赖注入与使用方式
多个上下文注册后，可以直接通过构造函数注入，EF Core 会自动解析各自实例。
- 控制器或服务中同时接收
OrderDbContext和ProductDbContext是完全合法的 - 确保它们的生命周期一致（推荐 Scoped），避免跨请求共享上下文实例
- 不要手动 new 上下文，也不要长期持有引用；用完即弃，由 DI 容器管理释放
迁移管理要分开操作
每个上下文的迁移文件彼此独立，命令行必须显式指定上下文类型。
- 添加迁移：
dotnet ef migrations add Init -c OrderDbContext - 更新数据库：
dotnet ef database update -c ProductDbContext - 迁移文件夹建议按上下文命名（如
Migrations/Orders、Migrations/Products），并用--output-dir参数控制生成路径
基本上就这些。多 DbContext 不复杂，但容易忽略职责边界和迁移隔离——理清“谁管什么、连哪里、怎么迁”，就能稳住架构底座。
