多个dbcontext需独立注册、隔离配置和迁移，避免连接串混淆、表迁移错乱及跨库查询异常，核心在于边界划分与使用规范。
多 DbContext 不是“能不能”的问题，而是“怎么划清边界、避免互相污染”的问题。直接注册多个 AddDbContext 就行，但连错库、迁错表、查串数据的坑，全出在配置和使用姿势上。
多个 DbContext 怎么注册才不冲突
每个 DbContext 必须单独调用 AddDbContext，不能共用一个注册语句。它们之间完全独立，DI 容器会按类型解析，不会混淆。
- 连接字符串必须分开配：在
appsettings.json里定义"OrderDbConnection"、"ProductDbConnection"等不同键名 - 注册时显式指定 Provider 和对应字符串：
options.UseSqlServer(builder.Configuration.GetConnectionString("OrderDbConnection")) - 生命周期统一用
Scoped（默认行为），别混用Transient或Singleton——后者会导致连接串固定、事务跨请求失效 - 如果用了
AddDbContextPool，记得每个上下文都单独配池，比如AddDbContextPool<orderdbcontext></orderdbcontext>和AddDbContextPool<productdbcontext></productdbcontext>
OnModelCreating 为什么不能写在一起
每个 DbContext 的 OnModelCreating 只能配置自己 DbSet<t></t> 对应的实体。写混了，迁移会生成错表、运行时报 InvalidOperationException: The entity type 'X' was not found。
- 订单上下文只配
modelBuilder.Entity<order>()</order>和LineItem，别碰用户或商品的映射 - 实体类可以复用，但配置必须隔离——哪怕两个上下文都用
User类，只要它不属于当前上下文的DbSet，就不该出现在这个OnModelCreating里 - 共享配置逻辑可抽成扩展方法，比如
ApplyUserConfigurations(this ModelBuilder builder)，但调用仍需在各自上下文中显式执行
迁移命令为什么总报“找不到 DbContext”
EF Core CLI 工具默认只找启动项目里的 DbContext。如果你把上下文放在类库，又没告诉它去哪找，就会卡在 Unable to create an object of type 'XDbContext'。
- 加
-c参数强制指定上下文类型：dotnet ef migrations add Init -c OrderDbContext - 加
--project指向上下文所在项目：dotnet ef migrations add Init -c OrderDbContext --project ./src/Orders.Infrastructure - 迁移文件夹必须隔离：用
--output-dir Migrations/Orders避免和Products的迁移混在一起 - 更新数据库也得指定上下文：
dotnet ef database update -c ProductDbContext，否则只跑默认那个
跨库查询时数据怎么拼起来
EF Core 不支持跨 DbContext 的 LINQ Join，SQL 层面也不通（除非用四部分名称且数据库允许跨库查询，如 SQL Server）。硬写会抛 InvalidOperationException: Cannot use a DbSet from multiple contexts。
- 应用层组合是唯一稳妥方式：先查
OrderDbContext.Orders.ToListAsync()，再用订单 ID 列表去ProductDbContext.Products.Where(x => ids.Contains(x.OrderId)) - 避免 N+1：用
Contains批量查，而不是循环查单条；ID 列表别超 2000 个，否则 SQL Server 会报参数过多 - 需要强一致性？上分布式事务（
TransactionScope）或最终一致性（发消息），别指望 EF Core 自动搞定
最常被忽略的是迁移隔离和跨库查询的物理限制——不是代码写不出来，而是数据库根本不让这么连。配置对了，命令跑通了，不代表业务逻辑就能绕过底层约束。
