CAP 不支持 Oracle，因其官方未提供 Oracle 存储实现，且 Oracle.ManagedDataAccess 不兼容 TransactionScope 与 CAP 的事务抽象层，强行接入会导致初始化失败或消息丢失；推荐用 Oracle 做业务库、PostgreSQL/SQL Server 做 CAP 消息库。
不能直接用 CAP 框架原生集成 Oracle —— CAP 官方不支持 Oracle 作为消息存储（CapPublisher 或 CapSubscriber 后端），也不支持 Oracle 作为事件总线的持久化介质。它只内置了 SQL Server、PostgreSQL、MySQL 和 RabbitMQ/Kafka 等主流组合。Oracle 不在支持列表中，强行接入会卡在初始化或事务提交阶段。
为什么 CAP + Oracle 会失败？
CAP 的核心依赖是「本地事务 + 消息表 + 补偿查询」三者强一致性，它要求消息表能参与业务数据库的本地事务（即同 Connection、同 Transaction）。但 Oracle.ManagedDataAccess 不支持 TransactionScope 跨资源协调，且 CAP 的 OracleCapStorage 实现从未被官方提供或维护。你若看到第三方 NuGet 包声称支持 Oracle，大概率是 fork 自老版本、未适配 .NET 8、也未处理 OracleTransaction 生命周期与 async/await 边界问题。
- 调用
capBus.PublishAsync()时，CAP 尝试在 Oracle 连接上开启事务并写入Published表 —— 若连接字符串含Enlist=true，会被忽略；若手动传OracleTransaction，CAP 内部无法识别或绑定 - CAP 的
ICapTransaction抽象层默认适配的是SqlTransaction/NpgsqlTransaction，没有OracleTransaction实现 - 即使绕过 CAP，自己建
CapPublished表并手写插入逻辑，也无法触发 CAP 的自动重试、死信投递、Dashboard 查询等能力
替代方案：用 Oracle 做业务库，CAP 用 PostgreSQL/SQL Server 做消息库
这是目前最稳定、可上线的组合。CAP 不强制要求消息库和业务库一致，只要求消息库自身支持本地事务和可靠写入。你可以把 Oracle 当纯业务数据源，CAP 单独部署一套轻量 PostgreSQL（甚至用 Docker 快速起一个）。
- 安装
CAP.PostgreSql或CAP.SqlServer，配置独立连接字符串，与 Oracle 无关 - 业务代码中仍用
OracleConnection操作 Oracle 表，但所有capBus.PublishAsync()都走 CAP 自己的连接池 - 确保发布动作发生在 Oracle 事务提交之后（推荐用
AfterCommitHook 或后台服务轮询状态表），避免“Oracle 写成功但 CAP 消息丢失” - 若必须强一致（如金融类场景），放弃 CAP 的自动补偿，改用 Saga：先在 Oracle 记录
OrderCreated状态，再发 MQ 通知下游，失败时查 Oracle 状态表驱动重试
如果非要用 Oracle 存 CAP 表，只能自己实现 ICapStorage
这不是配置问题，而是要重写整个存储层。你需要继承 ICapStorage，实现 StoreAsync()、GetPublishedMessagesOfNeedRetryAsync() 等 7+ 个方法，并确保每一步都使用 OracleCommand + OracleTransaction 显式控制。但要注意：
-
OracleTransaction不能跨async方法边界传递，所以所有 CAP 的异步操作（如重试、清理）必须同步化或改用OracleConnection.BeginTransaction(IsolationLevel.ReadCommitted)手动管理 - CAP 的 Dashboard 查询依赖 JSON 字段解析（如
Content列存 JSON），Oracle 12c+ 虽支持JSON_VALUE，但 CAP 的默认 SQL 构造器不生成 Oracle 兼容语法 - 没有单元测试覆盖，.NET 8 下
Oracle.ManagedDataAccess的OracleParameter对DateTimeOffset处理有偏差，可能造成时间字段错乱
真正卡住的不是代码能不能写出来，而是 CAP 的设计哲学和 Oracle 的事务模型根本对不上。与其花两周调试自定义存储，不如换 PostgreSQL —— 它和 Oracle 在事务语义、隔离级别、JSON 支持上更接近，且 CAP 对它开箱即用。
