必须使用 Oracle.ManagedDataAccess.Core ≥2.0 版本并启用 Async=true，全程 async/await 调用 ExecuteReaderAsync，配合 await using 管理资源，避免 Result/Wait、错误参数绑定及连接泄漏。
用 Oracle.ManagedDataAccess.Core 的 ExecuteReaderAsync 替代同步调用
oracle 官方 .net 驱动（oracle.manageddataaccess.core）从 2.0 版本起原生支持异步 api，但很多人仍习惯写 executereader()，这会直接阻塞线程池线程。必须显式使用带 async 后缀的方法，且整个调用链需保持 async/await —— 不能只在最外层加 async 却内部用同步方法“假装异步”。
常见错误现象：Task.Run(() => cmd.ExecuteReader()) 这种包装看似异步，实则只是把同步操作挪到后台线程，浪费线程池资源，且无法真正释放 I/O 线程。
- 确保 NuGet 引用的是
Oracle.ManagedDataAccess.Core（非旧版Oracle.ManagedDataAccess），版本 ≥ 2.0 - 连接字符串中必须启用异步支持：
;"Pooling=true;Connection Timeout=30;Unicode=true;Async=true"—— 注意Async=true是必需项，否则ExecuteReaderAsync会退化为同步执行 - 使用
using声明异步资源：await using var reader = await cmd.ExecuteReaderAsync();，避免手动调用DisposeAsync()
避免在异步方法里混用 Result 或 Wait()
这是导致死锁和线程饥饿的高发场景，尤其在 ASP.NET Core 请求上下文或 WinForms UI 线程中。一旦调用 task.Result，当前线程会被阻塞等待，而 await 所需的上下文可能正被该线程占用。
典型错误示例：var data = cmd.ExecuteReaderAsync().Result; —— 即使驱动本身支持异步，这样写也完全失去异步意义。
- 所有异步调用必须用
await，不要试图“同步等结果” - 若必须在非 async 方法中触发查询（如某些老框架入口），应明确接受同步代价：改用
ExecuteReader()+ 独立线程池任务，而非强行“转 async” - 检查所有中间件、过滤器、服务方法是否标记为
async Task，而非Task（后者易被误当成同步返回值）
注意 OracleCommand 参数绑定对异步的影响
参数绑定本身不阻塞，但错误类型或长度设置可能引发隐式同步行为。例如用 OracleDbType.LongVarChar 传超长字符串时，驱动可能内部缓冲并触发同步 I/O；又或者参数未显式指定 Size，导致驱动在预编译阶段反复探测长度。
性能影响明显：某次查询因未设 Size，平均耗时从 12ms 涨到 86ms，且 ExecuteReaderAsync 实际执行时间变长，违背异步初衷。
- 对
VARCHAR2类型参数，显式设置Size：cmd.Parameters.Add("name", OracleDbType.Varchar2).Value = "xxx"; cmd.Parameters[0].Size = 50; - 避免使用
OracleDbType.Clob或Long类型参数传递小文本，它们会触发额外流式处理逻辑 - 批量查询时，优先用
OracleBulkCopy而非循环 await 多个ExecuteNonQueryAsync，前者是真正的异步批量通道
连接泄漏会让异步优势彻底失效
异步查询快，不代表连接能随便开。Oracle 连接池默认上限 100，若 OracleConnection 未正确释放（比如没用 await using 或异常跳过 Dispose），连接会持续占用直到超时，最终抛出 ORA-12519: TNS:no appropriate service handler found。
容易被忽略的地方：在 try/catch 中只处理业务异常，却忘了连接对象本身的生命周期管理。
- 始终用
await using var conn = new OracleConnection(connStr);，而非var conn = new ...; await conn.OpenAsync();后手动 close/dispose - 不要复用
OracleCommand对象跨多个连接 —— 它持有对连接的引用，可能导致连接无法及时归还池 - 监控连接池状态：查
v$session视图中PROGRAM为 .NET 应用的会话数，若长期高于预期，大概率是连接未释放
