useoracle 是唯一合法入口，oracle.entityframeworkcore 6.0+ 已移除 oracleoptions 公开构造，仅支持 useoracle(connectionstring, builder => builder.enablebulkinsert()) 等安全链式配置；连接字符串须完整（不依赖 tnsnames.ora），必须使用 oracle.manageddataaccess 驱动及匹配版本的 oracle.entityframeworkcore，读写分离需通过不同连接字符串及显式 pooling=false 隔离连接池。
UseOracle 是唯一合法入口，别再传 OracleOptions
Oracle.EntityFrameworkCore 6.0+（对应 .NET 6 及以上）已移除 OracleOptions 类型的公开构造和配置入口。你不能再写 options.UseOracle(connectionString, o => o.EnableBulkInsert()) 并期望 o 是 OracleOptions 实例——它已被内部化，编译会直接失败。
正确路径只有一条：UseOracle 扩展方法接收两个参数：连接字符串 + OracleDbContextOptionsBuilder 类型的委托。后者只暴露有限但安全的链式配置项，比如：
-
EnableBulkInsert()—— 启用批量插入优化（需 Oracle Client 19c+） -
UseOracleSQLCompatibility("12")—— 强制兼容旧版语法（如不支持OFFSET ... FETCH的场景） -
MaxBatchSize(500)—— 控制 EF Core 生成的批量 DML 语句大小
常见错误是把 SQL Server 的 SqlServerOptionsExtension 习惯套过来，比如试图调用 o.CommandTimeout(30) 或 o.MigrationsAssembly(...) —— 这些属于通用选项，应放在 options 主体里，而非 oracleOptions 委托中。
连接字符串必须完整，tnsnames.ora 别指望自动生效
EF Core 的 UseOracle 不读取本地 tnsnames.ora 文件。如果你写 Data Source=ORCL_WRITE，而该别名只存在于某台开发机的 $ORACLE_HOME/network/admin/tnsnames.ora 中，部署到服务器时必然报 ORA-12154: TNS could not resolve the connect identifier。
稳妥做法是把连接信息展开成完整 Easy Connect Plus 格式：
Host=192.168.10.5;Port=1521;Service Name=ORCL;User Id=appuser;Password=xxx
或更明确的描述符形式：
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.10.5)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCL)))
注意：Service Name 和 SID 不可混用；Oracle 自治数据库要用 myadb_high 这类专用服务名，不能填实例名。
Oracle.ManagedDataAccess 是唯一推荐驱动
别碰 System.Data.OracleClient（已废弃）、也别用 Oracle.DataAccess（ODP.NET Unmanaged，依赖本地 Oracle Client DLL，x86/x64 极易冲突）。唯一能跨平台、免安装、版本可控的选择是 Oracle.ManagedDataAccess（NuGet 包）和它配套的 EF Core Provider：Oracle.EntityFrameworkCore。
版本必须匹配：
- .NET 6 + Oracle 19c/21c → 推荐
Oracle.EntityFrameworkCore 7.21.1 - .NET 8 + Oracle 23c → 用
Oracle.EntityFrameworkCore 8.22.1
如果引用了 Oracle.ManagedDataAccess 但没装 Oracle.EntityFrameworkCore，UseOracle 方法根本不会出现在 intellisense 里——因为它是后者的扩展方法，不是前者自带的。
连接池要拆开管，读写分离不能共用一个连接串
即使你暂时不做读写分离，也要意识到：Oracle 连接池默认按连接字符串全量哈希。如果连接串里只有用户名密码不同（比如读库用 readonly_user，写库用 app_user），EF Core 仍会复用同一池子——这在主从延迟敏感场景下极其危险。
真正隔离的方式是让读/写连接串在字符串层面就完全不同，例如：
- 写库：
User Id=app_user;Password=xxx;Data Source=(DESCRIPTION=...)(SERVICE_NAME=ORCL_WR);Pooling=true; - 读库：
User Id=ro_user;Password=yyy;Data Source=(DESCRIPTION=...)(SERVICE_NAME=ORCL_RO);Pooling=false;
关键点：Pooling=false 必须显式加在读库串里。否则连接可能被池子缓存并复用于后续写操作，绕过你的路由逻辑。
UseOracle 委托里的参数还能调用通用 EF Core 配置——这三个地方出错，占了实际项目中 80% 的 Oracle 连接失败案例。
