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 不复杂，但容易忽略职责边界和迁移隔离——理清“谁管什么、连哪里、怎么迁”，就能稳住架构底座。
